Skip Headers

Oracle ODBC Driver for Rdb® Release Notes
Release for Microsoft Windows


Oracle ODBC Driver for Rdb®

Release Notes

Release for Microsoft Windows

April  2019

This documentation contains information about the following topics:

1 Overview About This Release

This kit includes Version of the Oracle ODBC Driver for Rdb. This version is considerably different internally from the version 2 Oracle ODBC Driver for Rdb software.

2 Installation

This product is installed by the Microsoft Windows Installer, a completely different technology from that used by previous v3 releases of the Oracle ODBC Driver for RDB. TO INSTALL, YOU MUST FIRST DEINSTALL ANY EXISTING COPIES THAT WERE INSTALLED BY ORACLE INSTALLER. To do this, bring up the Oracle Installer from the original ODBC driver installation, select the Oracle ODBC Driver for RDB and click REMOVE.

Also note, IF YOU ARE UPGRADING FROM A VERSION OLDER THAN, YOU MUST FIRST DEINSTALL ANY EXISTING VERSIONS USING ADD/REMOVE PROGRAMS IN THE WINDOWS CONTROL PANEL. As of ODBC 3310, the installation includes a new copy of the SQLServices client API (SQSAPI32.DLL) and due to versioning issues, this file may not be replaced during an upgrade. Removing the old copy first will ensure the new SQLServices DLL is installed.

To install the Oracle ODBC Driver for RDB, extract the files in the installation kit into their own directory and run SETUP.EXE. The main ODBC libraries/DLLs will be installed into the Windows System directory and other supporting files will be installed into a directory you can select during the setup process.

To deinstall, go into control panel, select add or remove programs, select the Oracle RDB Driver for ODBC and deinstall...

3 Post-Installation

  1. Ensure that only one copy of sqsapi32.dll and/or sqsapi64.dll exists on your computer. The Oracle ODBC Driver for Rdb will not run with old versions of sqsapi32.dll or sqsapi64.dll.
  2. Use the Microsoft ODBC Administrator to configure your data sources. In a change from v2 releases, the name of the driver as it appears in the Administrator's list is "Oracle Rdb Driver". This will allow you to change existing v2 data sources (under the old name "Oracle ODBC Driver for Rdb") only when you are ready to do so. This name change brings the Rdb driver into alignment with all the other ODBC drivers. The formal name of the product remains the longer name.
  3. The v3 ODBC driver for Rdb uses the same configuration file as the Oracle ODBC driver, oraodbc.ini. This is a change from v2 when the file was named rdbodbc.ini. The section with driver-specific settings is now titled with "[Oracle Rdb Driver]".

4 Hardware Required

The Oracle ODBC Driver for Rdb requires a system configuration supported by Microsoft Windows 7 and higher

5 Software Required

Client Software Requirements

For TCP/IP transport, one of the following operating systems and minimum version is required:

Invalid handle error returned from SQLSetDescField(SQL_PRECISION)

Invalid handle error returned from SQLSetDescField(SQL_PRECISION) when using scaled numerics such as SCALED INTEGERS. Seen with the Microsoft OLEdb Provider for ODBC. Bug 29623751. Fixed in


Oracle ODBC driver for Rdb now is built with Microsoft Visual Studio 2010.

Previous versions of the Oracle ODBC driver for Rdb were built with tools included with Microsoft Visual Studio 2005.

Queries may fail When using the DECKANJI DLL for translating char and varchar

The DECKANJI dll is used to translate ASCII into certain Japanese character sets such as Hankaku Katakana and others. When using this DLL on chars and varchars queries may fail with Windows Protection faults and memory Access Violations on the client. This can happen when a multibyte character is split across buffers.

Some notes on this fix are as follows,

1) In the case retrieved data exceeds the certain buffer size, it's divided into two portions, and a DEC_KANJI(two bytes character) data is located on boundary, the size of actual record returned to user’s application is one byte shorter than the returned value to user application as a record length, and NULL is padded at the end of record. (eg: buffer size is 200byte and 230byte data in DEC_KANJI character set is translated into Shift-JIS in Oracle ODBC driver for Rdb, and DEC_KANJI(2bytes character) is located in 200th byte and 201st byte, user’s application will receive is 231byte as a record length but actual record returned to the user’s application contains 230 bytes data and one byte NULL at the end of record.). 2) In the case retrieved data exceeds the certain buffer size then it's divided into two portions, and the data includes Hankaku Katakana, the size of actual record returned to user’s application is shorter than a record length returned to user’s application, and NULL is padded on the end of record, how many bytes are short is the same as the number of Hankaku Katakana character included in the retrieved data. (eg: buffer size is 200byte and 230byte DEC_KANJI character set data include the number of 10 Hankaku Katakana data to be translated into Shift-JIS in Oracle ODBC driver for Rdb, the size of actual data returned to your application will be 220byte but a record length returned to user’s application will be 230byte and 10 byte are padded with NULL on the end of record.).

Redirect DriverLogging files to specific directory

DriverLogging is a diagnostic aid to help identify problems with the ODBC driver. This can be enabled by editing ORAODBC.INI and setting DriverLogging to a non zero value. Traditionally this trace file would be created in whatever the default directory was at the time the driver was loaded into memory. This can cause problems if the default directory is protected or restricted in some way. For this reason a new parameter was added to ORAODBC.INI called "Logfile Dir" that will allow the user to specify the directory to create the trace file. The specification must end with a \. For example, Logfile Dir = C:\MYLOGFILES\ Note, this file is only read when the driver is initialized. Restarting the application or rebooting the system may be required for this to take effect.

Setting SQLSetStmtAttr(SQL_ATTR_MAX_LENGTH) to values greater than 4294967294 causes General Protection Faults and Memory Access Violations.

Setting this attribute beyond the max size of 4294967294 would cause crashes in certain applications. Fixed in


Memory allocation failures and invalid results returned if API call includes the "REMARKS" column

Any API calls that return a "remarks" column such as SQLTables or SQLColumns may produce unpredictable results and once the error is encountered any subsequent API calls may also fail. Symptoms include memory allocation failures, general protection faults and invalid return values.     Bugs 23174524 and 23640371. 64 bit only. Fixed in

Incorrect value returned for SQLGetInfo(SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES2)

SQLGetInfo(SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES2) incorrectly indicated the driver can return the record count from a forward only cursor. SQLGetInfo(SQL_FORWARD_ONLY_CURSOR_ATTRIBUTES2) now indicates this count is not available
SQLGetDiagField (SQL_DIAG_CURSOR_ROW_COUNT) now returns SQL_SUCCESS with a value of -1 instead of SQLError

Previous versions of the ODBC driver returned an error when
SQLGetDiagField was called with the SQL_DIAG_CURSOR_ROW_COUNT qualifier. As of the driver returns SQL_SUCCESS with a value of -1 to indicate the count was not available.

         SQLGetDiagField no longer returns -100 on record 0

Previous versions of the driver returned -100 for SQLGetDiagField  if no errors were available for the previous statement. This is correct except if the application is asking for record zero (header record). As of a return status of -100 (SQL_NO_DATA) is no longer returned for record zero. SQL_NO_DATA is still returned if the application is asking for a record greater than zero and the record doesn't exist.

         SQLGetDiagField now returns a 64 bit result as needed for SQL_DIAG_CURSOR_ROW_COUNT and SQL_DIAG_ROW_COUNT

SQL_DIAG_CURSOR_ROW_COUNT and SQL_DIAG_ROW_COUNT are supposed to return a 64 bit value if they are on a 64 bit platform. As of this has been corrected.


    SQLStatistics may return invalid results

    The 10th parameter to SQLStatistics should return a "A" for an ascending index and "D" for a decending index and the data type for this is defined as a CHAR(1). Due to C null termination, if the buffer bound to column 10 is a char(1), the data was truncated and the value returned was simply a null. Fixed in

    SQLColAttributes(SQL_DESC_CONCISE_TYPE) may return invalid value for TINYINT

    The last parameter for the SQLColAttributes ODBC API call is suppied by the application and should be an address to a buffer to store whatever the application asked for, in this case SQL_CONCISE_TYPE. The ODBC driver only writes the low order bits of this buffer on this particular API call as per the ODBC specification and if the high order bits contained garbage, unexpected results would be returned. A recent version of Microsoft .NET has this problem.

    As of, we now clear the high order bits on this API call to work around this problem. Bug 17321709

    SQLTables only returns 30 characters of a table name although RDB supports 31 character table names

    Table names up to 31 characters are supported as of Bug 18176798

    Unable to enable driver or client logging with the 64 bit ODBC driver

    To enable driver logging, set network buffer size and other parameters, you set parameters in the ORAODBC.INI file located in the Windows directory. On 64 bit versions of the driver these parameters were not detected. As of, a new parameter block is included in the ORAODBC.INI file specifically for 64 bit applications.

    [Oracle Rdb Driver 64 Bit]
    Client Logging=0


    Memory Leak beginning with

    A memory leak was inadvertantly included in a bug fix for truncated floating point values in This is fixed in


    Intermittant Duplicate Cursor Name errors on MultiThreaded Applications

    When connection pooling is enabled in the Microsoft ODBC Driver manager and hold cursors are enabled, intermittant Duplicate Cursor Name errors may be returned to the application. This only applies to implicit cursor names that are generated by the driver. Explicit cursor names provided by the application were not affected. Fixed in

    Enabling DriverLogging in ORAODBC.INI may result in Windows Protection Fault

    Fixed in

    Microsoft Excel Connection Wizard fails with errors indicating it cannot obtain a list of tables

    Fixed in

    Microsoft Access 64 bit returns a Memory Allocation Failure when trying to import or link a table

    Fixed in

    Problems with Floating Point values when mixing RDB ODBC with IBM DB2 ODBC

    When calling the RDB ODBC driver and the IBM DB2 ODBC driver from the same application, floating point values may be truncated  if the DB2 driver was called first. If the RDB ODBC driver was called first, the values were correct.. Fixed in


    Unexpected HP OpenVMS intrusion alerts since upgrading to SQLServices

    The Microsoft ODBC specification indicates if an application uses SQLDriverConnect with certain options, the driver should attempt a connection with the connect string that was supplied with the call and if that fails, the user dialog is to be displayed to prompt the user for any missing information. This initial connect attempt was causing an unwanted intrusion alert on the OpenVMS account.

    A new checkbox has been added to the data source dialog screen that will allow you to control whether this initial connection attempt is done.  Click Options and the Allow Blank Password checkbox will appear in the Database Options section. When checked, the driver will perform it's initial connect attempt regardless of whether or not a password was supplied.  When unchecked, the driver will not perform this initial connection attempt and will prompt the user immediately if a password was not supplied. Note, if a password was supplied on the connect string, the initial connect attempt will be performed regardless of the DSN setting.  If Allow Blank Password is unchecked and the user does not enter a password when prompted, the connection WILL be attempted and an intrusion alert generated if the OpenVMS account is not configured to accept a blank password.

    The following connect string attribute has been added to support this functionality.

    RPD=0     Same functionality as if the Allow Blank Password is not set
    RPD=1     Same functionality as if the Allow Blank Password is set

    SQLGetTypeInfo returns 32 bit values on certain columns using the 64 bit driver

    When using SQLGetTypeInfo to determine what data types are available from the data source, the return values for LITERAL_PREFIX, LITERAL SUFFIX and a few others were correct for the 32 bit driver but incorrect for 64 bit. This has been fixed in

    Microsoft .NET applications may return invalid results if a VARCHAR was selected immediately after  literal NULL

    Applications that use SQLGetData to retrieve results may return wrong results for a VARCHAR column if the VARCHAR was immediately after a literal NULL in the select list. For example, assuming FLD3 is a VARCHAR,

    select null, fld3 from test_table

    may return incorrect results for fld3. Bug # 10247440. Fixed in

    Microsoft SQLServer linked servers may insert incorrect values if inserting into a scaled integer and the length of the value is less than the scale.

    If using SQLBindParameter to insert a scaled integer value with an SQL_C_NUMERIC data type and the scale is larger than the value being inserted, the scale could be lost. For example, with an SQL_C_NUMERIC, inserting a .01 is actually inserted as a 1 with a scale of 2.  Since the scale is 2 but the length is 1, the scale would be lost. If a .10 is inserted with a scale of 2, it would be inserted as a 10 with a scale of 2 and this does NOT fail.  Bug # 10082658. Fixed in

    The RIGHT scalar function may return incorrect values when using literals.

    For example, right('abcdefghijk',3) would return 'hij' instead of 'ijk'. Bug # 10139201. This is fixed in


    New Features

    Specify TCPIP Port or DECNET Object in the ODBC Data Source

    Added the ability to specify an alternate TCPIP port or DECNET Object as part of the data source.

    Previously, to specify an alternate port for an ODBC data source, the user had to edit SQSAPI32.INI to indicate what port to use for a particular server system. One major drawback to this was that all connections to the specified server had to use that port.

    Now, you can specify the TCPIP port/DECNet object when creating the data source. To specify the port/object, click on OPTIONS in the data source you wish to modify and specify port/object at the bottom of the screen.

    Connect String Attributes

    The following connect string attributes are now supported in SQLBrowseConnect, SQLDriverConnect and SQLConnect,

    PRT=     ; Specifies the TCPIP Port number or DECNET Object for the connection.

    Performance Enhancement

    Interaction with Oracle SQLServices for RDB has been enhanced with the use of the new client API calls now available for Windows in the SQLServices 7.3 Windows API. See the SQLServices documentation for more information. Depending on the application, this enhancement may result in a considerable performance improvement on queries with large result sets or applications that perform a large number of catalog queries. .

    Other changes and bug fixes in this version

    SQLGetInfo returned SQRDB64.DLL on SQL_DRIVER_NAME with the 32 bit ODBC driver. The correct filename is SQRDB32.DLL for 32 bit. This is fixed in

    Fetching a negative floating point value may cause Windows Protection faults. Bug 9289538. Fixed in

    Microsoft Access unable to link tables using RDB ODBC This was caused by an incorrect return value for ODBC SQLGetInfo(SQL_IDENTIFIER_QUOTE_CHAR). Fixed in

    A workaround for the Oracle 10g Gateway for ODBC returning [Oracle][ODBC]Numeric value out of range was inadvertently left out in previous versions.  This functionality was restored in

    Queries using parameter markers and bound variables may cause Windows Protection Faults if the parameters are floating point data types (SQL_DOUBLE and SQL_REAL). Bug 9350083. Fixed in



    Availability of a native 64 bit ODBC driver for RDB

    Starting with ODBC, a 64 bit ODBC Windows driver is available for Oracle RDB. The 64 bit driver contains all of the changes as per the ODBC specification and is built to run on a 64 bit Windows machine.  See the Microsoft ODBC Programmers Reference, Chapter Introduction to ODBC, ODBC 64-bit Information section for more details on the changes that were made.  Note, to use the 64 bit ODBC Driver for RDB, you also need to have a 64 bit application running on a 64 bit Windows configuration. You cannot use a 32 bit application to access the 64 bit driver. This is a Windows restriction and is not specific to any ODBC drivers.

    Driver files for the 64 bit ODBC Driver for RDB have been renamed. SQSAPI32, SQRDB3, SQRDBS3 and SQRDBESUS have been renamed to SQSAPI64, SQRDB64, SQRDBS64 and SQRDBESUS64.

    It is supported to have both 32 bit and 64 bit ODBC drivers installed at the same time. 64 bit ODBC data sources will be displayed with the 64 bit Microsoft ODBC Administrator and used by native 64 bit applications and 32 bit data sources will be displayed by the 32 bit Microsoft ODBC Administrator and used automatically by 32 bit applications. It is recommended you install both 32 bit and 64 bit drivers in environments where mixed 32 bit and 64 bit applications will be used. 

    In the future, it is intended to release all new versions of the ODBC driver on both the 32 bit and 64 bit platforms as needed so any bug fixes and new functionality will be available on both platforms.

    Note for 64 bit Microsoft SQLServer users

    Early 64 bit Microsoft Windows versions included a version of the Microsoft OLEDB Provider for ODBC that prevented updates to Oracle RDB databases linked via the Oracle ODBC Driver for RDB if the update statement had a where clause that included a character data type. This problem has been fixed in the Microsoft OLEDB Provider that comes with later Windows versions.

    The minimum Microsoft WDAC version required to use the 64 bit Oracle ODBC Driver for RDB with 64 bit Microsoft SQLServer is 6.0.6001.18000 (or higher). This version comes with Microsoft Vista and newer versions of Windows (Windows 2008, Windows 7, etc). New Microsoft WDAC versions are released via Windows service packs. Please contact Microsoft for more information on future MDAC/WDAC updates on older versions of Windows. 


    Other Enhancements and Bug fixes

    Microsoft SQLServer may return only 1 row for a linked table select query. This was caused by an optimization in the Microsoft C Compiler and was fixed in RDB ODBC but not release noted.

    SQLSpecialColumns returned a result set that had some of the data on the wrong order and the wrong data types as defined on the ODBC specification. Bug # 8483035. Fixed in

    Binding a BIGINT parameter during insert or update and fetching into that parameter causes an unhandled Win32 exception.  Bug 9024978. Fixed in

    If the "Use Multischema" key contains a blank or any character except a zero, the multischema functionality would be enabled. The default was intended to be that Multischema Support was disabled unless explicitly enabled. Fixed in



    Enhancements to Catalog support

    Additional functionality has been added to support multiple catalog and schema modes with the
    ODBC driver. These schema options are available in the options section in the Microsoft ODBC Adminstrator
    and are located in the schema options frame. These new options can also be enabled using keywords in the
    ODBC connection string. The basic modes of operation are as follows,


    If the "Use Catalog and Schema" box is NOT checked, Multischema support is disabled. This is basically the
    same functionality as in previous versions of ODBC (pre 3.2) except that errors will not be returned if the application
    specifies a catalog or schema in a catalog API call. Applications that supply search criteria based on catalog or
    schema names will work as though a catalog/schema was not specified. Catalog functions that return catalog
    and schema names will return NULL for those values. Several values in SQLGetInfo and both Connect
    and Statement attributes are changed to reflect no catalog support.


    If the "Use Catalog and Schema" box IS checked, Multischema support is enabled. If the Oracle RDB database is an actual
    multischema database, true multischema support is exposed by the driver. Enter the actual Catalog and Schema to default to
    in the boxes provided. On connect, the driver will execute a "set catalog" and "set schema" statement  based on the defaults
    you have specified. Calls to SQLSetCurrentCatalog will issue the appropriate "set schema" statements. Catalog functions that
    return catalog and schema names will return the actual names for those values as defined in the database. Several values in
    SQLGetInfo and both Connect and Statement attributes are changed to reflect full catalog support.


    If the "Use Catalog and Schema" box IS checked, Multischema support is enabled. If the Oracle RDB database is NOT an actual
    multischema database, simulated multischema support is exposed by the driver. Whenever an ODBC API calls requests the
    current catalog or schema, the values entered in the Default Catalog and Default Schema boxes will be returned. All catalog
    functions that return CatalogName or SchemaName will return these same values. THE ONLY VALID VALUES FOR DEFAULT
    select the "Use Catalog and Schema" box.  Calls to SQLSetCurrentCatalog will be ignored. Several values in SQLGetInfo and both
    Connect and Statement attributes are changed to reflect full catalog support.

    Connect String Attributes

    The following connect string attributes are now supported in SQLBrowseConnect, SQLDriverConnect and SQLConnect,

    MSE=     ; Enables the same functionality as the "Use Catalog and Schema" box for the data source. Valid values are
    MSE=0  disables multischema support. MSE=1 enables multischema support.

    DCG=     ; Enables the same functionality as the Default Catalog box for the data source. For example, RDB$CATALOG for a single schema
    database or ADMINISTRATION for the sample corporate multischema RDB database.

    DSH=     ; Enables the same functionality as the Default SCHEMA box for the data source. For example, RDB$SCHEMA for a single schema
    database or PERSONNEL for the sample corporate multischema RDB database.

    The following SQLGetInfo attributes change depending on what mode is selected




    Actual db name 

    Current Schema


    Empty String

    DoubleQuote (")


    Empty String















    Actual db name

    Current Schema


    Empty String



    Empty String










    The following API calls implement the new connect string and DSN values as described above


    The following API calls change behavior depending on what mode is selected


    These return catalog and schema as described above. Wildcards on catalog and schema
     supported when appropriate. If Multischema is disabled as described above, NULL will be returned for Catalog
    and Schema names.


    These return catalog and schema as described above. In addition, Sending in a wildcard for CatalogName or Schema name with the other fields
    being an "Empty String" will cause the driver to just list the available catalogs and schemas as described on the ODBC specification. In this same
    example, if Multischema is disabled, no rows are returned for available catalog or schema.

    Added attributes for SQLGetInfo

    SQLGetInfo(SQL_XOPEN_CLI_YEAR) returns 1995 instead of DRIVER_NOT_CAPABLE

    Other changes and bug fixes

    Included Microsoft C 8.0 RTLs if not already installed on the system.


    • Oracle ODBC for RDB now uses Microsoft Windows Installer to install the driver and it's associated files. This eliminates the dependencys on JAVA and Oracle Installer as was in previous versions.
    • Driver rebuilt using the Microsoft Visual Studio 2005 C++ compiler and incorporates all the new secure string functions internally to prevent buffer overruns.
    • Intermittant memory corruption on SQLDriverConnect.
    • Actual length of string variables being converted to numerics will be tested without padding before returning [Oracle][ODBC]Numeric value out of range.

    This is a workaround to allow the 10g Oracle Database Gateway for ODBC to work with the RDB ODBC driver. On numeric literals, the gateway binds string variables with a length of 65 and pads the left side of the value with spaces. The workaround will strip the padding off the string and reverify the length against the target data type before returning the out of range error. Bug # 7424413


    • Certain values would cause rounding issues when using a SQL_C_NUMERIC structure and scaled integers

    An SQL_C_NUMERIC structure contains an Integer value and a scaling factor. To determine the actual value, the value was divided by scale. This was done in a floating point operation and could causing rounding of certain values. This is no longer done in floating point and the rounding should be eliminated.

    • The workaround for Powerbuilder legacy applications ProcOutParams=NO has been rebuilt. This functionality was accidently removed as part of the rebuild of and prevented older Powerbuilder applications from upgrading. Note this functionality is deprecated and will go away in some future version. Use of this function for Powerbuilder may be incompatable with other ODBC applications that process parameters correctly. Bug # 6606888
    • SQLColumns and SQLStatistics return "[Oracle][ODBC]Optional feature not implemented" if a schema was specified on a single schema database. These parameters are now ignored if the database is a single schema database. 
    • SQLDriverConnect incorrectly retried failed connections regardless of type of failure

    If a data source specifies an attach string and is connecting to a preattached service, the ODBC driver will retry the connection without the attach string before returning an error. This was intended to retry only on certain failures, ie, SQLSRV-E-NOPREPCONN, but retried on all failures regardless of error. This could result in incorrect errors being reported on SQLDriverConnect. Fixed in


    • "Mulitschema is Enabled" Restriction Removed

    In prior versions, any multischema database must have had the "multischema is disabled" clause specified in the attach statement. This restriction has been removed.

    • Change in Default Behavior for the SQL_DATABASE_NAME Attribute

    The SQLGetInfo function used to return the database file specification for its SQL_DATABASE_NAME attribute. This default behaviour has now been changed to return the "RDB$CATALOG" value instead to better match the ODBC specification.

    The previous default behavior is still available, but only on a database-by-database basis. To re-establish the previous behavior for a database, edit the C:\WINDOWS\ORAODBC.INI file and add the following:


    where <data-source-name> is the value specified as the database source name in the ODBC Data Source Administrator tool. For example:


    • Support Catalogues and Schemas from the ODBC Driver for Rdb

    Enhancement request 2578939. Support for catalogs and schemas has been added to the SQLColumns, SQLTables, SQLProcedures, SQLProcedureColumns, SQLPrimaryKeys, SQLForeignKeys, and SQLStatistics functions. Each of these functions will now use the caller-provided catalog and/or schema name in the building of the result list. In multischema databases, the values provided will be matched against those in the RDB$CATALOG_SCHEMA and RDB$SYNONYMS tables. In non-multischema databases, the only valid catalog values that the caller can provide to these functions are "RDB$CATALOG" or null, and the only valid schema values are "RDB$SCHEMA" or null.

    In multischema databases, these functions will always load the associated catalog and schema values from the RDB$CATALOG_SCHEMA table into the result set. For non-multischema databases, these functions will ONLY load catalog or schema values into the result set if one has been passed to the function by the caller. Therefore, for non-multischema databases, the only valid catalog values returned are "RDB$CATALOG" or null, and the only valid schema values returned are "RDB$SCHEMA" or null.


    Enhancement request 4474577. In previous versions, the ODBC driver for Rdb would not work correctly when accessed via a variety of Microsoft tools. This was caused by no implementation for catalogs and schemas in the driver. The problem was compounded by the fact that these Microsoft tools also used the value from SQL_DATABASE_NAME (which previously was the database file specification) as a catalog value. As detailed above, both issues have been fixed in

    • Value for the SQL_CATALOG_NAME Attribute

    Since catalog and schema suppost has been implemented in the ODBC Driver for Rdb, the SQLGetInfo function will now return "Y" for the SQL_CATALOG_NAME attribute.


    • BIGINT is not shown correctly after upgraded ODBC driver for Rdb from 2.10

    For an application that used the RDO ODBC layer, the ODBC driver for Rdb would return the incorrect length for a BIGINT column. This would result in the BIGINT column value being truncated. Fixed in


    For an application that used the .NET 2003 ODBC interface, the ODBC driver for RDB would return the incorrect max length fir CHAR and VARCHAR columns. Fixed in


    • Test Connection Button is Confusing

    In the ODBC Data Source Administrator, the "Test Connection" button associated with the definition of an Oracle Rdb ODBC Driver setup would not fully test the connection. Therefore, it was possible to receive a "successful connection" message eventhough the connection of the actual database would fail. Now, the "Test Connection" button will connect to the service and also perform a simple query on the database thus more fully testing the connection. Bug 5009477. Fixed in


    After upgraded to Oracle ODBC Driver for Rdb from 2.10.17, dbkey is not shown correctly. Only first 8 digits are shown. Bug 4686153. Fixed in


    • SQLColumns returns incorrect results

    When using SQLColumns to returns metadata information, if columns were bound as SQL_C_DEFAULT, the SQLFetch to get the data would return "Unsupported data conversion", "Feature not yet implemented" errors and other assorted symptoms. This fix is required for SPSS users. Fixed in

    • SQLDescribeCol incorrectly returns SQL_VARCHAR for List of Byte Varying

    Oracle Rdb List of Byte Varying data type (also known as segmented strings) was being described as a SQL_VARCHAR data type. This should have been SQL_LONGVARCHAR). Fixed in


    • Zero length VARCHAR always treated as null terminated

    Zero length varchar parameters were always treated as null terminated strings which resulted in invalid data being inserted in some cases. This was actually caused by a restriction in the SQLServices API. As of, we terminate zero length varchars at the first character position to avoid inserting invalid data. Bug # 2258990. Fixed in

    • SQLColumns returns invalid string length on column 7 for char and varchar

    SQLColumns returned zero on column 7 (COLUMN_SIZE) for all char and varchar columns. This should be the column length. Bug # 3513432. Fixed in

    • A fetch following SQLTables may return Driver Not Capable

    If Columns 2 and/or 4 are bound prior to an SQLTables API call, the SQLFetch following the SQLTables call returned "Driver not Capable" Fixed in

    • SQLBrowseConnect returned an incomplete connect string

    SQLBrowseConnect returned a connect string missing several attributes and had confusing labels on some of the ones that were there. Added several attributes, fixed confusing labels and added some defaults. Fixed in

    • SQLDriverConnect did not return connect string when ProxyAccess=2

    Specifying ProxyAccess=2 in ORAODBC.INI causes any SQLDriverConnect, regardless of fDriverCompletion to be treated as SQL_DRIVER_NOPROMPT. When this functionality was used, a return connect string was not returned by the driver. Bug # 3551112. Fixed in

    • SQLDriverConnect returned invalid hold cursor value on return connect string

    The connect string returned by SQLDriverConnect returned cso=1 (NOHOLD) regardless of what was specified in the DSN. Bug #3510675. Fixed in

    • SQLFetchScroll now supported

    The SQLFetchScroll(SQL_FETCH_NEXT) API call is now supported for forward only cursors. The behavior is essentially the same as SQLFetch. Attempts to use FetchOrientation other than SQL_FETCH_NEXT will result in HY106 Fetch Type Out of Range. Enhancement request # 3240525. Added in

    • Added functionality to fetch ahead processing

    FetchAhead is a user adjustable parameter in %windows%\OraODBC.INI that tells the driver to fetch more than 1 record at a time per network buffer. For example, if FetchAhead=NO and an application needs to fetch 50 rows from a table, this will result in 50 network buffers (plus other overhead) being sent over the network individually. If FetchAhead=YES, the driver will fetch as many rows in one network buffer as the application indicates by setting SQLSetStmtAttr(SQL_ATTR_ROW_ARRAY_SIZE) to a value greater than 1. If this value is not set or set to 1, the driver will fetch 10 rows by default. As of, if FetchAhead=MAX and SQL_ATTR_ROW_ARRAY_SIZE is set to 1, the driver will fetch as many rows as will fit in a 64k buffer. For applications that fetch large amounts of data and do not specify SQL_ATTR_ROW_ARRAY_SIZE, this may result in a significant performance improvement. Note, this has no effect if HOLD_CURSORS are enabled. Enhancement request # 3580850

    • SQLStatistics may fail on fetch if column 11 is bound to SQL_C_SBIGINT

    Column 11 of the result set returned by SQLStatistics should return an integer containing the cardinality of the table or index being reported on. If this column was bound to SQL_C_SBIGINT, the fetch to get the result set from SQLStatistics would fail with SQL_ERROR (General Error). Bug #3625244. Fixed in

    • SQLTables did not return system tables if TableType was not specified

    If TableType was not specified on an SQLTables API call, Rdb system tables were excluded by default. As of, this is no longer the case. Bug # 3633129

    • Calling a stored procedure with output parameters resulted in a General protection fault

    If an application binds an output parameter from a stored procedure and that output parameter is a Timestamp or Date VMS data type, the application may crash with a Windows Protection Fault on SQLExecute. This only affected date/time data types and does not affect other data types. Fixed in Bug # 3713878


    • Duplicate cursor name using Powerbuilder

    When an application issued SQLCancel just before SQLFreeStmt, sometimes the statement did not get fully released. This caused duplicate cursor name errors on certain applications. Problem was reported by users using Powerbuilder. Fixed in

    • Memory Leak using Microsoft ADO

    When an application issued SQLCancel just before SQLFreeStmt, sometimes the statement did not get fully released. This caused a memory leak in the SQLServices executor for ADO users. Fixed by the same bug fix detailed above for Powerbuilder users. Fixed in

    • Can not override service name in driver login dialog

    When the service specified in a data source is overridden in the ODBC driver login dialog box, the driver still used the service specified in the data source. The service specified in the driver login dialog was ignored. Fixed in (Bug 3069180)

    • HELP button fixed

    The HELP button in the ODBC Administrator setup dialog box was not working. Fixed in

    • Optimization in Connecting to pre-attached service.

    Performance has been improved when an application asks for the database name after connecting to a preattached service. Fixed in

    • General Error after SQLFreeStmt

    Certain varieties of SQLFreeStmt calls did not clean up completely. Fixed in (Bug 2837973)

    • SQL data type out of range with VARBYTE LIST

    Depending on whether columns are bound before or after the statement is SQLPrepared, a data-type out of range error would result for VARBYTE LIST columns. Fixed in (Bug 3026082)

    • Incorrect parsing of literal values

    Literal values containing right curly bracket characters "}" were being processed incorrectly. Fixed in v3.1.0.0 (Bug 2789433)

    • SQL_NO_DATA from SQLExecute for ODBC v2 applications

    SQLExecute was incorrectly returning SQL_NO_DATA status for ODBC v2 applications when it should have been returning SQL_SUCCESS. Fixed in v3.1.0.0 (Bug 2972659)


    • SQLExecute returns error when calling stored procedure

    If a stored procedure is called that returns a VARCHAR value, a "Descriptor type out of range" error may be returned. This is fixed in

    • Unhandled Exception when using long hostnames

    When a host/server name is specified that is greater than 20 characters in length, an "Unhandled Exception" may be returned by the operating system when the attempt to connect is made. This is fixed in

    • Invalid precision error returned when fetching SQL_BIGINT.

    An attempt to insert/update a value defined as BIGINT into the database from the ODBC datatype SQL_C_UBIGINT or SQL_C_SBIGINT would result in an invalid precision error being returned to the application. Fixed in

    • SQLGetTypeInfo failed to return valid data in certain columns

    When an application used SQLGetTypeInfo to retrieve information about data types supported by the database, string truncation errors may be returned for 1 or more of the columns in the result set. Fixed in This was first seen using Microsoft Query.

    • SQLColAttributes returns invalid value for

    When an application calls SQLColAttributes(SQL_DESC_SEARCHABLE) to determine if a column can be used in a where clause, the driver always returned SQL_PRED_NONE (not searchable). This would cause Microsoft Visual Basic programs using ADO to return errors if adUseServer is used for the query. This is fixed in

    • Unable to insert into List of Byte Varying

    When inserting a value into a List of Byte Varying, the statement appeared to complete but the data was never stored in the database. This is fixed in


    • Incorrect values returned when bound size does not match DB data size

    If a SMALLINT column is bound as LONG, and more than one row fetched at a time (SQL_ROWSET_SIZE > 1), later rows would partially overlap earlier rows, resulting in data corruption. Fixed in

    • ANSI DATE and TIME data truncated

    DATE and ITME data types were being converted incorrectly such that more bytes were needed for the values than the specification calls for. This would typically show up as truncation errors when fetching dates as CHAR types. Fixed in

    • Fetch stops prematurely on array fetch

    If the ROW_ARRAY_SIZE was increased after a Fetch had been done any subsequent calls to Fetch would only retreive the number of rows specified the first time. Microsoft SQLServer would interpret this as meaning that the end of data had been reached. This has been fixed in v3.0.2.5.

    • Fetch-ahead not working efficiently

    If the ROW_ARRAY_SIZE was set to a small value this reduced the number of rows that fetch-ahead would get in a single network exchange. If ROW_ARRAY_SIZE was later increased, the fetch-ahead amount remained at the lower value, resulting in excessive network traffic. This was related to the problem described above. The minimum fetch-ahead will now be 10 rows, or however many will fit in the available buffer space, whichever is less. If the ROW_ARRAY_SIZE is increased, the fetch-ahead value will now follow. Fixed in v3.0.2.5.

    • Invalid Precision error when binding parameters

    When binding parameters of type DECIMAL or NUMERIC and specifying a precision greater than 18 digits an error was returned. In fact this is correct behavior as 18 is the maximum precision allowed for these types. But since v2 did not enforce this limit several customers have complained so the test has been removed for those two types. If an application actually tries to pass in a value with too many digits it will get an error reported by SQL on the server side, but no error will now be reported by SQLBindParameter. Changed in v3.0.2.5.


    • Binding as SQL_C_DEFAULT erroneously bound as CHAR instead

    Bind to a column with C-type SQL_C_DEFAULT was incorrectly treated as binding as CHAR when applied to various internal queries, such as SQLGetTypeInfo, SQLStatistics, SQLColumns, etc. This only caused problems typically with columns of type SMALLINT, but could have with other numeric types. Microsoft ACCESS would show an "internal error" when trying to create a link to an RDB table. Fixed in


    • Numeric columns bound as binary integer types give wrong results

    Some "C" data types were not being properly handled. This mostly affected numeric results. Another symptom of the same problem was "string truncation" errors from MSQRY32 when expanding the list of columns within a table. Fixed in


    • SQLColAttributes returning zero for SQL_COLUMN_LENGTH
    • SQLColAttribute and SQLColAttributes returning null column name
    • SQLColumns returning no rows if table name contains underscore

    Similar problem in SQLTables. Was fixed in, broken again in, now fixed again in Beware of a bug in Microsoft MSQRY32 (which is used by Microsoft Excel) which can return erroneous SQLColumns results for a table containing an underscore in its name if there is another table with the same name but with some other character in place of the underscore. For example, expanding table "A_B" when there is another table "AXB" will result in a display of all the columns in both tables. Microsoft Access does not have this bug.


    • SQLTable returned rows in wrong order

    The rows returned by SQLTable are now sorted so that system relations come before user relations, and tables come before views. Fixed in

    • SQLSetConnectAttr failure message when connecting

    Microsoft's ODBC Driver manager delays calling the driver's SetConnectAttr function until the application calls SQLConnect. SetConnectAttr was complaining that the LOGIN_TIMEOUT option was not supported but it made the Connect itself appear to have something wrong with it. SQLSetConnectAttr has been changed to quietly accept attempts to set the LOGIN_TIMEOUT value, even though it is not used. This is the same behavior used in the earlier v2 driver. Fixed in

    • SQLGetTypeInfo fetch fails if columns bound first

    If the columns are bound before SQLGetTypeInfo is called, the subsequent fetch failed. This was caused by an incorrect converting of type codes internally. Fixed in

    • Attempts to set the CURRENT_CATALOG attribute failed

    The v3 driver was incorrectly reporting (via SQLGetInfo) that it supported changing the CATALOG name. This was in error. Now it reports that no such functions are supported, and this will prevent layered software such as Microsoft's ADO from making the SQLSetConnectAttr call. Fixed in

    • "Movefirst" operation in VB resulted in wrong rows fetched

    The driver was not defending against attempts to move the cursor backwards and would keep moving forward instead of giving a "Not supported" error. This has been changed so that any attempt to move the cursor other than forward will give an error and VB/ADO will work around the problem.

    • SQLColAttributes returning wrong values

    The ODBC driver provides two ways of discovering attributes of returned data (data type, length, etc). MS Visual Studio .NET uses a different one than ADO and this uncovered a bug in SQLColAttributes which has now been fixed in v3.0.2.1.

    • Could not retreive output parameters from stored procedures

    If a stored procedure had output parameters, various obscure errors would result on a SQLExecxute trying to call the procedure. The exact error depended upon the combination and ordering of INPUT, OUTPUT, and INPUT-OUTPUT parameters in the call. Fixed in

    • Binding a BIGINT(2) INPUT parameter as SQL_NUMERIC failed

    Support was missing for mapping the SQL_NUMERIC datatype correctly to the underlying SQL/Services datatypes. Fixed in

    • Wrong version number in driver log file

    The driver log file (controlled from the oraodbc.ini file) contained the wrong driver version number. Fixed in

    • Performance problem with array fetching with FETCH_MANY

    When a large array size was used to fetch multiple rows at a time, the fetch_many code would persistently attempt to fill that array even when an end-of-data condition was reached. This could take a couple minutes if the array size was large (several hundred). Fixed in


    • SQLTables had wrong column labels

    The column labels returned by a SQLTables query contained RDB's internal column names rather than the names required by the ODBC specification. Fixed in

    • HELP file difficult to find

    An item has been added to the Start menu to make it easier to find the Windows HELP file for the Oracle ODBC for RDB driver.

    • Procedures without output parameters do not work

    SQLBindParameter was unable to bind to output parameters although it returned a SUCCESS status. Depending on the ordering of IN, OUT, and INOUT parameters in the called procedure this could produce different symptoms. Fixed in

    • Parameters in Connect String ignored

    The value of parameters specified in the Connect string were being ignored if the parameter already had a value in the Data Source definition. Fixed in

    • SQLSetStmtAttr returned "Driver not capable"

    The SQLSetStmtAttr function was failing with the "not capable" status code for things it could have easily done. Fixed in

    ·         Performance problem when fetching large amounts of data Starting in V3.0.1.0 the ODBC driver was not implementing the fetch-ahead feature that was present in the V2 driver. This resulted in lower performance. This functionality has been restored in


    • SQLColumns returning wrong date/time info

    Columns of a date/time type were incorrectly described, with old v2 type codes and with wrong data in the subtype and consise type columns. This also applies to SQLProcedureColumns. Fixed in

    • Character sets translated incorrectly

    Starting with v3.0.1.0 characters in the DEC-KANJI character set were not being translated correctly to the SJIS set used by Windows in situations where rows were bound before the SQLFetch call. This bug was inherited from the Oracle8 driver that served as a base for the Rdb v3 driver effort. Presumably similar problems would turn up with any similar use of the translation (TLL option) feature, regardless of the character set used. Fixed in v3.0.1.3.

    • SQLTables not returning all types requested

    A parsing error in SQLTables could result in not all requested relation types being returned. If several types were requested and the order was just right, some would be ignored. For example, "TABLE,VIEW,SYSTEM TABLE,SYNOMYMS" would not return VIEW relations. This had nothing to do with the types requested, only the order in which they were specified. Fixed in

    • SQLProcedureColumns not returning all columns

    SQLProcedureColumns gained some additional report columns in ODBC v3 which had been left out by an oversight. Fixed in


    • SQLColAttribute returns null column name

    SQLColAttribute was returning a null string for the column name. Fixed in version

    • Integers returned as NUMERIC did not work

    The spec for ODBC v3 introduced a new datatype "NUMERIC". ADO uses this new type in the latest MDAC release. The v3 driver had an incorrect implementation of the conversion. Fixed.

    • DBKEYs returned as binary

    The v2 driver converted DBKEY values into hex character strings for the application, and converted them back again when used as parameters. The v3 driver was not doing this. Fixed.


    • SQLTables returned no tables

    The release had a bug caused by a compiler misoptimization which resulted in calls to SQLTables with null arguments returning no matches at all. Fixed.

    • HELP files installed under wrong name

    The release installed the HELP files with the wrong filenames. Fixed.


    • Various installation and deinstallation problems

    The V2 driver used the now unsupported Oracle Installer. The V3 driver uses the same installer technology as most other Oracle products, the Oracle Universal Installer. This is proving to be more reliable, and deinstallations are much cleaner. Fixed.

    • BIGINT data types not properly converted

    If the application requested BIGINT data to be delivered in binary (as 8-byte integers) rather than as character strings, errors would result. The correct conversions now take place in both directions. The V2 driver did not support BIGINT at all. Fixed.


    • Kanji translator restored

    The DLL that does translations between Latin and Japanese character sets, DECKAN32.DLL, was missing from previous beta releases. Fixed.

    • Missing columns

    Requests to list columns within a table would return no column names for tables with an underscore in their names for some programs. The Query Wizard in Microsoft Query (which is also used by Microsoft Excel to import data) and Quattro Pro were known to encounter this problem. Fixed.

    • Segmented Strings

    A bug in buffer management for LIST OF VARBYTE and LIST OF VARCHAR datatypes, present since v2, would sometimes cause extra strings of null bytes to be inserted, or sections of data to be omitted, when fetching the data. In addition, the V2 driver could not properly deal with any buffers longer than 32767 bytes. Fixed.

    • SQLGetTypeInfo, SQLColumns, SQLTables, and SQLDescribeCol

    Metadata queries using these functions did not return consistent results and in some cases returned completely incorrect results. Fixed.

    • Type mapping

    Earlier beta releases did incorrect mapping of RDB datatypes to ODBC SQL datatypes. Many RDB types would be reported as VARCHAR. In there were still some problems. Fixed.

    • Multithread support

    Version 2 of the ODBC Driver for RDB had primitive support for multithreading, which was basically a single semaphore around everything. Although this allowed the driver to be used in multithreaded applications, it provided no true parallel access. The v3 driver has finer grained locking so that threads may do simultaneous ODBC operations as long as they do not try to modify the same contexts at the same time. Earlier beta releases did not have this functionality complete, but it is present in v3.0.0.4. In v3.0.0.5 we replaced the thread locking mechanism with a better implementation (shared by the Oracle8 ODBC driver) which should improve parallelism even more. Fixed.

    • SQLTables

    Any call requiring Rdb to distinguish a TABLE from VIEW returned no rows on Oracle Rdb 7.0 or later, if partitioning was used. The way the metadata query was done gave wrong results if any of the newly defined flag bits in the RDB$FLAGS column of the RDB$RELATIONS system table was set. Fixed.

    • Formatting of SQL_REAL data

    The ODBC specification requires that real data be represented in 13 bytes; 9 bytes for mantissa, including sign and decimal point, plus 4 bytes for exponent. SQL (on VMS) returns real data in 14 bytes, with 10 bytes in the mantissa. When the ODBC driver truncated this to the correct 13 bytes, the low order digit of the exponent got chopped off, rendering the value incorrect by possibly many orders of magnitude. The correct behavior is to remove the lowest order mantissa digit instead. Fixed.

    • Incorrect conversion of ROWID values

    When operating with Oracle Developer/2000 and Rdb v7.0.2 or later, ROWID values were not being delivered to Developer/2000 in a correct format. The ODBC driver was looking for columns with a name of "DBKEY" and did not recognize "ROWID" as a synonym. Fixed.

    12 Known Software Problems

    1. This release of the Oracle ODBC Driver for Rdb does not support the use of Fetch Ahead when holding cursors. Fetch Ahead is internally disabled when the hold cursors attribute is defined in the Data Source.
    2. The Oracle Rdb ODBC driver does not support the use of ODBC date and timestamp tag literals in a single statement that references columns of both VMS-style and ANSI-style date/time format data types.

    ODBC allows applications to specify date and timestamp literals using tags that vendor-specific ODBC drivers convert to a database-specific format. For example {ts '1996-06-26 20:47:50.350000'} and {d '1996-02-26'}.

    Rdb supports 2 styles of date format: the older VMS-style (DATE VMS data type) format and the newer ANSI-style (DATE ANSI and TIMESTAMP data types) format. However, SQLExecDirect has no way to know whether a particular date/time tag literal is targeted at a VMS format or an ANSI format data type. Therefore, to support date/time tag literals, SQLExecDirect first converts the tag literals to the VMS date format and tries to prepare the statement. If the prepare fails, it then converts the tags to the ANSI date format. Because the driver converts all tags to either VMS format or ANSI format, you cannot mix columns of both data types in a single statement.

    1. The ODBC Driver detects "ROWID" or "DBKEY" values by their names. If you rename such a column, as in the statement


    the driver will not recognize that the column is a DBKEY and will not properly present the data for the application.


    13 Network Communications

    The Oracle ODBC Driver for Rdb uses the Oracle SQL/Services client (sqsapiw.dll or sqsapi32.dll) for all network communications.

    The sqsapiw.ini or sqsapi32.ini file contains optional configuration information that overrides previously set parameters. The following parameters can be overridden when set in the sqsapiw.ini or sqsapi32.ini file:

    • Transport type as set using the ODBC Administrator
    • Client logging as set in the Oracle ODBC Driver for Rdb section of the win.ini or oraodbc.ini file.

    The contents of the sqsapiw.ini or sqsapi32.ini file are commented out. If you wish to use either .ini file, you must remove the semi-colons (;) in the leftmost column of lines with no adjacent space and specify values for parameters you wish to change.

    Copyright and Trademark Acknowledgments

    Copyright (c) 1993, 2019, Oracle Corporation. All Rights Reserved.

    The Programs (which include both the software and documentation) contain proprietary information of Oracle Corporation; they are provided under a license agreement containing restrictions on use and disclosure and are also protected by copyright, patent, and other intellectual and industrial property laws. Reverse engineering, disassembly, or decompilation of the Programs is prohibited.

    The information contained in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error free. Except as may be expressly permitted in your license agreement for these Programs, no part of these Programs may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Oracle Corporation.

    If the Programs are delivered to the U.S. Government or anyone licensing or using the programs on behalf of the U.S. Government, the following notice is applicable:

    Restricted Rights Notice Programs delivered subject to the DOD FAR Supplement are "commercial computer software" and use, duplication, and disclosure of the Programs, including documentation, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programs delivered subject to the Federal Acquisition Regulations are "restricted computer software" and use, duplication, and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-19, Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

    The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be the licensee's responsibility to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of such applications if the Programs are used for such purposes, and Oracle Corporation disclaims liability for any damages caused by such use of the Programs.

    Oracle is a registered trademark, and Oracle Rdb, Oracle SQL/Services, and are trademarks or registered trademarks of Oracle Corporation. Other names may be trademarks of their respective owners.


    Oracle Logo