SQL/R A.02.99 supports the Eloquence eloqdb6 database from version A.06.10 to B.08.10 on all platforms. ODBC drivers are available for the Windows, Linux and HP-UX platforms.
If a view is joined with other table(s) or view(s), empty values may be returned for view columns that are specified more than once, for example, if a view column is specified in the SELECT column list as well as in the WHERE condition.
This problem did not affect 32-bit SQL/R versions.
A literal integer value exceeding the 32-bit integer range (less than -2,147,483,648 or greater than 2,147,483,647) was wrongly truncated to 32-bit instead of being converted to a floating point value.
The SQL/R server log messages below were issued:
D0: Inter-process-communication failed: child process not found (sockfd=...) P0: User ... failed to logon at ...: no more user licenses available
This was caused by an internal race condition where a newly started SQL/R child process was not registered in time by the SQL/R master process.
The following problems have been fixed since the A.02.97 release:
The following problems have been fixed since the A.02.96 release:
Date fields may now be stored in X/U/B database items. The item size must be appropriate to store the encoded date value, for example X8 for a YYMD encoding. When submitting a date value to the database, it is left aligned if the item size is greater than the length of the encoded value.
The precision of single-precision floating point database values was reduced to 6 digits to avoid rounding problems in certain cases.
The following problems have been fixed since the A.02.95 release:
This was caused by a side effect of a change in SQLR A.02.90.
This was caused as a side effect of the SQLSpecialColumns() implementation introduced with SQLR A.02.87.
The following problems have been fixed since the A.02.94 release:
The following problems have been fixed since the A.02.93 release:
This may also affect multiple date/time comparisons of the same column with different values combined in an OR expression, as this is internally optimized to an IN expression.
This problem is a side effect of the 1970-01-01 date value fix introduced in SQL/R A.02.86 (#3671).
The following problems have been fixed since the A.02.92 release:
For example, a DATE <> 0 comparison in a join condition might cause unexpected results. This was caused by a side effect of a change in SQLR A.02.90.
This config item was used to work around a bug in ODBC client drivers before A.02.50 but could result in precision loss status in some cases.
The following problems have been fixed since the A.02.91 release:
Assertion failed: rem_sz >= acc->scan_ctx->rec_size
For example, a statement like below could trigger this problem if the specified ROWID did not exist:
SELECT * FROM CUSTOMERS WHERE ROWID=42
For example, both of the statements below are valid:
SELECT * FROM CUSTOMERS C, ORDERS O WHERE C.CUSTNO=O.CUSTNO SELECT * FROM CUSTOMERS AS C, ORDERS AS O WHERE C.CUSTNO=O.CUSTNO
If the SQL/R ODBC driver is invoked through an ODBC driver manager such as unixODBC, and this driver manager exports the ODBC function SQLGetPrivateProfileString(), this function is now used to read a data source configuration from the odbc.ini file.
Previously, the SQL/R ODBC driver used its own functionality to read a data source configuration from the odbc.ini file. However, this requires that the ODBCINI environment variable is set to appropriately refer to the odbc.ini file, unless it is located in the /etc directory (/etc/odbc.ini) or the invoking user's home directory ($HOME/.odbc.ini).
If the driver manager does not export SQLGetPrivateProfileString(), the SQL/R ODBC driver falls back to using its own functionality to read a data source configuration from the odbc.ini file.
This driver library is named libsqlrodbc64.
However, as a 64-bit API was required but no standard was available yet, implementations such as the unixODBC driver manager derived the 64-bit ODBC API from the 32-bit ODBC API. This 64-bit API definition, nowadays known as LEGACY_64_BIT_MODE is incompatible with the meanwhile published Microsoft 64-bit ODBC API definition, as it uses 32-bit data types for SQLLEN, SQLULEN and SQLSETPOSIROW, while Microsoft defines these data types as 64-bit.
As a consequence, when using 64-bit ODBC on HP-UX or Linux, the application must match the API of both the driver manager and the ODBC driver.
If the application uses the LEGACY_64_BIT_MODE API, the driver manager and the ODBC driver must both support this API. For SQL/R, this means that the libsqlrodbc ODBC driver library must be used.
If the application uses the Microsoft 64-bit ODBC API (also known as REAL_64_BIT_MODE), the driver manager and the ODBC driver must both support this API. For SQL/R, this means that the libsqlrodbc64 ODBC driver library must be used.
The following problems have been fixed since the A.02.90 release:
This problem is a side effect of the 1970-01-01 date value fix introduced in SQL/R A.02.86 (#3671).
Please note that this workaround simply fakes success on a SQLSetConnectOption(SQL_ATTR_ENLIST_IN_DTC) invocation to work around an integration problem with Microsoft SQL Server. The SQL/R ODBC driver does not support the OLE transaction protocol necessary to integrate into a distributed transaction. If used in a trigger procedure, the SQL/R ODBC driver performs an autonomous transaction.
The following problems have been fixed since the A.02.89 release:
In SQL/R versions before A.02.86, a NULL date or time value would match a numeric zero or an empty string in a comparison.
For example, SELECT ... WHERE orderdate = 0 would match all NULL orderdate values if orderdate is a date type.
As a side effect of the 1970-01-01 date value fix introduced in SQL/R A.02.86 (#3671), this was no longer possible. A NULL date or time value would then only match an IS NULL comparison.
The SQL/R A.02.90 version restores the previous behavior. Any NULL date or time value now matches either a numeric zero, an empty string or an IS NULL expression.
For example, if database DB1 and database DB2 both contain a table named CUSTOMERS and both of these tables have a column named CUSTNO the statement below returned wrong results:
SELECT * FROM DB1.CUSTOMERS, DB2.CUSTOMERS WHERE DB1.CUSTOMERS.CUSTNO=DB2.CUSTOMERS.CUSTNOThe problem did not occur when table alias names were used, as in:
SELECT * FROM DB1.CUSTOMERS CUST1, DB2.CUSTOMERS CUST2 WHERE CUST1.CUSTNO=CUST2.CUSTNO
The following problems have been fixed since the A.02.88 release:
The following problems have been fixed since the A.02.87 release:
panic: ImageDb6::cvdb2dbl, file src/sql/image6/iconvrt.cxx, line 396On the client side, this caused a connection failure error message.
The following problems have been fixed since the A.02.86 release:
The following problems have been fixed since the A.02.85 release:
The following problems have been fixed since the A.02.84 release:
On 64 bit Windows, choosing to install the SQL/R ODBC driver causes both the 32 bit and the 64 bit ODBC drivers to be installed.
Please note that on 64 bit Windows there are two separate ODBC control panels present. The default ODBC control panel, located in the Administrative Tools control panel folder, is the 64 bit ODBC control panel. This is used to manage ODBC data sources that use a 64 bit ODBC driver, to be used by 64 bit programs.
The 32 bit ODBC control panel is named odbcad32.exe and is located in the WINDOWS\SysWOW64 directory (C:\WINDOWS\SysWOW64\odbcad32.exe). This is used to manage ODBC data sources that use a 32 bit ODBC driver, to be used by 32 bit programs.
The following problems have been fixed since the A.02.83 release:
The following problems have been fixed since the A.02.82 release:
With P or Z items, identical values may have a different binary representation. For example, the values 42 (unsigned) and +42 (positive) have the same numeric value but differ in their binary representation.
Due to a problem in the Eloquence database server, identical values with a different binary representation did not match in all cases. If SQL/R uses an index access method with a P or Z item, this could cause an incomplete result.
This problem was fixed in Eloquence B.07.10 with patch PE71-0805070 (eloqdb6 database server patch as of 2008-05-07).
In cases where it is not possible to update to this or a superseding patch, a workaround was implemented in SQL/R. When this workaround is enabled, SQL/R internally uses a "greater-or-equal" comparison instead of an "equal" comparison with P and Z item values and then transparently adjusts the result.
To enable this workaround, the WorkAroundSignAmbiguity configuration item may be set in the [Config] section of the SQL/R odbc.cfg file:
WorkAroundSignAmbiguity = 1If this is set to 1, the workaround is enabled. The default is 0 which disables the workaround.
Please note that if the Eloquence B.07.10 database server patch PE71-0805070 (or superseding) is installed, this workaround should be disabled for optimum performance. Backgrund: If the workaround is enabled, the number of transferred results is reduced to ensure an early EOF detection. If the number of matching results is high, this could have an impact on performance.
The following problems have been fixed since the A.02.81 release:
For example, the statement below:
CREATE VIEW CUST_VIEW AS SELECT CUSTNO,NAME FROM CUSTOMERS;resulted in:
CREATE VIEW CUST_VIEWAS SELECT CUSTNO,NAMEFROM CUSTOMERS;
Ini::FindSection() failed: Invalid argument, errno=22, iniapi.c(180)
This was a side effect of a modification in the SQL/R A.02.78 version (#3490).
The only platforms where a 64 bit SQL/R server is currently available are Linux x86_64 and Linux ia64.
The following problems have been fixed since the A.02.80 release:
This improves compatibility to common ODBC applications and utilities.
Example for previous SQL/R OUTER JOIN syntax with a common join condition (still valid and supported):
SELECT ... FROM {OJ <TABLE> LEFT OUTER JOIN <TABLE>
LEFT OUTER JOIN <TABLE>
ON <CONDITION1> AND <CONDITION2> }
WHERE ...
Example for alternative OUTER JOIN syntax now recognized in addition:
SELECT ... FROM {OJ <TABLE> LEFT OUTER JOIN <TABLE> ON <CONDITION1>
LEFT OUTER JOIN <TABLE> ON <CONDITION2> }
WHERE ...
For example:
SELECT ... FROM <TABLE> LEFT OUTER JOIN <TABLE> ON <CONDITION1>
LEFT OUTER JOIN <TABLE> ON <CONDITION2>
WHERE ...
panic: size == sizeof(xtime_t), file ... exprval.cxx ...
The problem was introduced with SQL/R A.02.68 when the internal DATE/TIME data type was extended to 64 bit. In a GROUP BY context, however, a 32 bit data type was still assumed.
panic: size == sizeof(long), file ... exprval.cxx ...
The only platforms where a 64 bit SQL/R server is currently available are Linux x86_64 and Linux ia64.
The only platforms where a 64 bit SQL/R server is currently available are Linux x86_64 and Linux ia64.
The only platforms where the 64 bit SQL/R client programs are currently available are Linux x86_64 and Linux ia64.
The following enhancements have been introduced with the A.02.80 release:
To define and use the case insensitive index functionality the Eloquence B.07.10 patches as listed below are required:
Patch PE71-0802120 or newer: eloqdb6 database server
Patch PE71-0801252 or newer: schema utility
Patch PE71-0801253 or newer: prschema utility
Patch PE71-0801254 or newer: dbutil program
A case insensitive index is defined by setting the CI index option.
For example in the schema file:
INAME (CI) = NAME;
Alternatively you may use dbutil to create or modify an index item to become case insensitive:
CHANGE IITEM INAME FLAGS CI;
If a column is used in a WHERE condition with the UCASE() or LCASE() SQL functions and a case insensitive index is available for this column, SQL/R uses this index to perform an optimized access.
For example:
SELECT * FROM CUSTOMERS WHERE UCASE(NAME) LIKE "MAR%" SELECT * FROM CUSTOMERS WHERE LCASE(NAME) LIKE "mar%"
Both statements would match on CUSTOMERS.NAME beginning with "MAR" in a case insensitive manner, for example on "MARTIN" and "Marcus".
If the database provides a case insensitive index on CUSTOMERS.NAME SQL/R will use this index in this context.
In the WHERE condition, if a column is used with the LEFT() or SUBSTRING() SQL functions and an index is available for this column, SQL/R uses this index to perform an optimized search on a partial value.
For example:
SELECT * FROM CUSTOMERS WHERE LEFT(NAME,3) = "MAR" SELECT * FROM CUSTOMERS WHERE SUBSTRING(NAME,1,3) = "MAR"
Both statements would match on CUSTOMERS.NAME beginning with "MAR", for example on "MARTIN" and "MARCUS".
Please note that a SUBSTRING comparison only uses an index if it starts with 1, as in the example above.
This may also be combined with a case insensitive comparison, such as:
SELECT * FROM CUSTOMERS WHERE UCASE(LEFT(NAME,3)) = "MAR" SELECT * FROM CUSTOMERS WHERE SUBSTRING(LCASE(NAME),1,3) = "mar"
Both statements would match on CUSTOMERS.NAME beginning with "MAR" in a case insensitive manner, for example on "MARTIN" and "Marcus".
The following problems have been fixed since the A.02.77 release:
The following problems have been fixed since the A.02.76 release:
The following problems have been fixed since the A.02.75 release:
The collating sequence is defined as a language specifier and either a "fold" or "nofold" modifier separated by a @ character, such as "french@nofold".
A "fold" sort order interleaves upper- and lowercase characters such as AaBbCc...Zz, where a "nofold" sort order separates upper- and lowercase characters, such as ABC...Z abc...z. For example: sortorder = german@nofold
The supported collating sequences are installed in the directory /opt/sqlr2/lib/nls/collate on HP-UX and Linux or the lib/nls/collate subdirectory below the SQL/R installation directory on Windows.
If not defined, string values are ordered by their binary value (in ASCII order).
Please note that this problem only affects the HP-UX pa11 releases of SQL/R A.02.70 and newer. SQL/R versions A.02.69 and before as well as the HP-UX pa11_1020 releases of SQL/R A.02.70 and newer are not affected.
The following problems have been fixed since the A.02.74 release:
The following problems have been fixed since the A.02.73 release:
CtFile::AllocIndexFile(...) failed on OPNFIL: ... errno=2 CtFile::ReadData(...) failed on fread(): ... errno=2This was caused by a race condition when accessing temporary results from concurrent sessions (#3317).
The following problems have been fixed since the A.02.72 release:
The following problems have been fixed since the A.02.71 release:
The following problems have been fixed since the A.02.70 release:
The following problems have been fixed since the A.02.69 release:
The following problems have been fixed since the A.02.68 release:
The following problems have been fixed since the A.02.67 release:
The following problems have been fixed since the A.02.66 release:
[Marxmeier][SQL/R ODBC Server]S1000 - Something went wrong (#99)
The following problems have been fixed since the A.02.65 release:
The following problems have been fixed since the A.02.64 release:
The following problems have been fixed since the A.02.63 release:
The following problems have been fixed since the A.02.62 release:
WaitForMultipleObjects() failed, 87: The parameter is incorrect.
The following problems have been fixed since the A.02.61 release:
Using an IF or IFNULL argument could cause a "37000 - Invalid expression (#48)" error. This affected the SQL functions ATAN2, BAND, BIT, DIV, MOD, POWER, ROUND, TRUNCATE, DATE, TIME, TIMESTAMPADD and TIMESTAMPDIFF.
The following problems have been fixed since the A.02.60 release:
The following problems have been fixed since the A.02.59 release:
The following problems have been fixed since the A.02.58 release:
The following parameters are currently supported in the SQLDriverConnect and SQLBrowseConnect ODBC functions:
The following problems have been fixed since the A.02.57 release:
This bug was exposed by the changes in Eloquence patch PE70-0502070.
The following problems have been fixed since the A.02.56 release:
With some eloqdb6 server versions (before eloqdb6 patch level PE70-0502070) this invalid request could cause an eloqdb6 abort with a message like below:
Assertion failed: keydef->k_len == k_ctx->idx_keysz
server panic: Aborting on internal failure, file fseq.c, line 830
With Eloquence patch PE70-0502070 installed this results in a SQLR error message like below:
[Marxmeier][SQL/R ODBC Server]S1000 - Something went wrong (#99)
The following problems have been fixed since the A.02.55 release:
The following problems have been fixed since the A.02.53 release:
SELECT * FROM ORDERS WHERE ORDERDATE >= '2004-12-01'
Previously, this resulted in a data type clash error because CHAR and DATE/TIME are different data types.
The following CHAR formats are recognized:
| YYYYMMDD | - | date without separators, example: '20041201' |
| YYYY-MM-DD | - | ISO date format, example: '2004-12-01' |
| DD-MON-YYYY | - | Oracle default date format, example: '01-DEC-2004' |
| MM/DD/YYYY | - | American date format, example: '12/01/2004' |
| DD.MM.YYYY | - | European date format, example: '01.12.2004' |
| HHMMSS | - | time without separators, example: '140925' |
| HH:MM:SS | - | standard time format, example: '14:09:25' |
| HH:MM:SS.FF | - | time format with fraction (ignored), example: '14:09:25.00' |
Notes:
The following problems have been fixed since the A.02.52 release:
The following problems have been fixed since the A.02.51 release:
When security is set to db, the user configuration in odbc.user and access lists in odbc.dsn are ignored. The DSN is considered writable, as specified by the EnableWrite configuration item and the permissions associated with the database login.
The following problems have been fixed since the A.02.50 release:
The following problems have been fixed since the A.02.48 release:
By default the ODBC server does not return the SQL_DOUBLE type (and uses SQL_FLOAT instead) to work around a driver bug in ODBC drivers before version A.02.50 that could cause an application abort. However OpenOffice (and possibly other applications) requires this to be set (and an updated driver) to work correctly with floating point results.
The default is "readonly" or "limited" if a WriteList configuration item is present. We do not recommend to enable "full" write mode.
The following problems have been fixed since the A.02.47 release:
The following problems have been fixed since the A.02.46 release:
The following problems have been fixed since the A.02.45 release:
The following problems have been fixed since the A.02.40 release:
The following problems have been fixed since the A.02.39 release:
Error message:
Unable to resolve table dependencies
The following problems have been fixed since the A.02.38 release:
SELECT ... FROM table
WHERE 350000 <= item AND item < 360000
In this case the first relational operator (<=) was not evaluated
correctly due to operand order.
The following problems have been fixed since the A.02.37 release:
The following problems have been fixed since the A.02.36 release:
The following problems have been fixed since the A.02.35 release:
For example:
CREATE VIEW SQLR.CU(CUSNO,CUSNAME)
AS SELECT CUSNO,CUSNAME FROM CUSTOMER
WHERE CUSNO LIKE "12%";
Please note:
For example:
select *
from {oj customer left outer join address
on address.custno=customer.custno and address.type="KD"};
In this example the condition address.type="KD" was ignored.
For example:
select *
from order,{oj customer left outer join address
on customer.adrid = address.adrid}
where order.custno=customer.custno;
Only a single outer join relation can be specified per SELECT statement.
The following problems have been fixed since the A.02.34 release:
The following problems have been fixed since the A.02.33 release:
The following problems have been fixed since the A.02.32 release:
The following problems have been fixed since the A.02.31 release:
The following problems have been fixed since the A.02.28 release:
The following problems have been fixed since the A.02.23 release:
The following problems have been fixed since the A.02.22 release:
The following problems have been fixed since the A.02.21 release:
The following problems have been fixed since the A.02.20 release:
The following problems have been fixed since the A.02.19 release:
The following problems have been fixed since the A.02.18 release:
The following problems have been fixed since the A.02.15 pre-release:
The following problems have been fixed since the A.02.14 pre-release:
The following problems have been fixed since the A.02.13 pre-release:
The following problems have been fixed since the A.02.12 pre-release:
The following problems have been fixed since the A.02.10 pre-release:
The following problems have been fixed since the A.02.09 pre-release:
FIELD qual.field CONVERT TO DATE [("encoding"[,baseyr])];
FIELD qual.field CONVERT TO TIME [("encoding")];
Where encoding describes the date field encoding in the database and baseyr provides an additional option for this encoding. This is important when a date field is used to access an index (in a join or optimizing the WHERE clause) because SQL/R must encode a value according to conventions used in the database.
The following date encodings are supported:
| "GREG" | number of days since base year (default 1972) |
| "YMD" | YYMMDD encoding, relative to base year (default 1900) |
| "Y2MD" | YYMMDD encoding, split at given year (default 1970) |
| "YYMD" | YYYYMMDD encoding |
| "UNIX" | seconds since 1970 |
For example:
FIELD qual.xx CONVERT TO DATE("YMD");
A value of 990424 is understood as 1999-04-24
FIELD qual.xx CONVERT TO DATE("YMD",1950);
A value of 490424 is understood as 1999-04-24
FIELD qual.xx CONVERT TO DATE("Y2MD",1960)
A value of 200424 is understood as 2020-04-24
A value of 990424 is understood as 1999-04-24
FIELD qual.xx CONVERT TO DATE("YYMD");
A value of 19990424 is understood as 1999-04-24
The following time encodings are supported:
| "HM" | 100 * hour + minute |
| "HMS" | 10000 * hour + 100 * minure + second |
| "HM60" | 60 * hour + minute |
| "HMS60" | 3600 * hour + 60 * minute + second |
For example:
FIELD qual.xx CONVERT TO TIME("HMS");
A value of 131512 is understood as 13:15:12
Please note that currently due to internal limitations a year value before 1901 or after 2036 will cause a conversion error (resulting in a NULL value).
The following problems have been fixed since the A.02.08 pre-release:
The following problems have been fixed since the A.02.07 pre-release:
The following problems have been fixed since the A.02.05 pre-release:
The following problems have been fixed since the A.02.04 pre-release:
The following problems have been fixed since the A.02.03 pre-release:
The following problems have been fixed since the A.02.02 pre-release:
In order to manually register the SQL/R ODBC Server with the Windows Service Control Manager you must execute sqlrodbcd.exe with the -install argument:
To unregister, use the command: sqlrodbcd -remove
Please make sure you unregister the SQL/R ODBC Server before you
uninstall the SQL/R software.
# # SQL/R related services # sqlrodbc 8003/tcp # SQL/R ODBC
where the first column specifies the service name ("sqlrodbc") and the second column the associated port number and protocol ("8003/tcp"). The installation program takes care that the selected port number is not already used otherwise.
In rare cases it might be necessary to modify this preset configuration, for example if the port number does not match the one configured on other systems.
The location of your SERVICES file depends on your Windows version:
The location of the SQL/R configuration directory depends on where SQL/R has been installed. All SQL/R configuration files are installed in the etc subdirectory of the SQL/R installation directory. This is usually C:\Programs\Marxmeier\SQLR\etc.
Each configuration file is responsible for a specific part of the SQL/R ODBC Server configuration:
| odbc.cfg | This is the general server configuration file. |
| odbc.user | In this file all users are defined who are allowed to access the ODBC server. |
| odbc.dsn | This file defines all accessible data sources on the server. |
Windows XP:
Windows 2000:
Windows NT:
Locate the SQLRODBC entry in the list and select it with the mouse. On Windows XP/2000, open the Properties dialog, either from the menu or using the context menu (right mouse button). On Windows NT, click the Startup... button to open the Startup Options dialog:
When you have setup the Startup Options, you can define additional arguments for the SQL/R ODBC Server as an option. This is usually not required since all settings are normally provided in the odbc.cfg configuration file. However this can be used for tracking down problems (e.g. starting the SQL/R ODBC Server temporarily with different log options).
Possible arguments are:
-d flags = log flags (debug mode) -l name = log file name -s name = service name -h name = http service name
| Option | Description | Equiv.* |
|---|---|---|
| d flags | Specifies the server debugging log flags. | LogFlags |
| l name | Specifies the server log file. | LogFile |
| s name | The service name (as defined in the SERVICES file) or the port number where the server should listen for requests. The default value is sqlrodbc. | Service |
| h name | If you want to make use of the HTTP status diplay feature of the server, use this option to specify the service name or port number where the server should listen for HTTP requests. | HttpService |
For example, if you wish to specify a different TCP service name (the default is "sqlrodbc"), you could enter the following into the Startup Parameters field:
-save -s 8567This will make the SQL/R ODBC Server listen to the TCP/IP port number 8567. The leading -save argument makes this command line persistent, so that the same arguments are used each time the SQL/R ODBC Server is started. If you do not specify the -save argument this command line will be used only once.
If you want to make sure that the command line is empty and that any persistent command line is deleted, just specify -save without any additional arguments.
At this point, everything is configured and the SQL/R ODBC Server can be started:
If you did not specify a log file, the SQL/R ODBC Server will write log messages to the Windows Event Log. In case the SQL/R ODBC Server does not start the Event Log will probably contain an error message pointing out the cause of the problem. You should also periodically check the Event Log in order to get aware of possible configuration problems.
Windows XP:
Windows 2000:
Windows NT:
Having started the SQL/R ODBC Server for the first time after installation, the Application Log should already contain a few entries noting that the SQL/R ODBC Server was successfully installed and started.
Command syntax:
net start SQLRODBC net stop SQLRODBC
To access the SQL/R ODBC Server, you provide an URL like this:
http://server:port/
where server is the host name or IP number of the system running the SQL/R ODBC Server and port is the port number used for HttpService in the odbc.cfg file.
Please refer to the URL http://www.marxmeier.com/sqlr. The previous SQL/R ODBC documentation is available in PDF format on the SQL/R web page.
First, the sample database should be installed in an Eloquence eloqdb6 database environment which must be already setup and running.
The following instructions install the SQL/R sample database in your default eloqdb6 server:
schema -u dba db.schema dbcreate -u dba db dbimport -u public -vs db.exp db
Notes:
For the English version:
[SQL/R Example] Database=localhost:eloqdb/db Repository=C:/Programs/Marxmeier/SQLR/share/db.e/db.rep
For the German version:
[SQL/R Example] Database=localhost:eloqdb/db Repository=C:/Programs/Marxmeier/SQLR/share/db.g/db.rep