SQLColAttributes(SQL_DESC_CONCISE_TYPE) may return invalid value for TINYINT

Memory Leak beginning with 3.3.2.2

Version 3.3.2.2

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 3.3.2.2

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

Version 3.3.2.1

Unexpected HP OpenVMS intrusion alerts since upgrading to SQLServices 7.3.0.3

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 3.3.2.1.

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

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 3.3.2.1

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 3.3.2.1.

Version 3.3.2.0    

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,

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 3.3.2.0.

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

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

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 3.3.2.0.

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 3.3.2.0

Version 3.3.1.0

Availability of a native 64 bit ODBC driver for RDB

Starting with ODBC 3.3.1.0, 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 3.3.0.1 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 3.3.1.0

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

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 3.3.1.0.

Version 3.3.0.1

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,

MULTISCHEMA DISABLED

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.

MULTISCHEMA ENABLED ACTUAL

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.

MULTISCHEMA ENABLED SIMULATED

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
CATALOG AND DEFAULT SCHEMA IN THIS CASE IS RDB$CATALOG AND RDB$SCHEMA. This will be the default when you
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

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

SQLBrowseConnect
SQLDriverConnect
SQLConnect

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

SQLTables
SQLColumns
SQLPrimaryKeys
SQLForeignKeys
SQLProcedures
SQLStatistics

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.

SQLTables

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
SQLGetInfo(SQL_MAX_ASYNC_CONCURRENT_STATEMENTS) returns 0 instead of DRIVER_NOT_CAPABLE

Other changes and bug fixes

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

Version 3.3.0.0

• 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 3.0.0.0 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 3.3.0.0

Version 3.2.0.0

• "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:

[<data-source-name>]
DatabaseNameSource=USE_FILE_SPECIFICATION

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

[PERSONNELDB]
DatabaseNameSource=USE_FILE_SPECIFICATION

• 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.

• SQLTABLESW - OPTIONAL FEATURE NOT IMPLEMENTED

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 3.2.0.0.

• 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.

Version 3.1.0.4

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

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

• APP FAILS AFTER UPGRADE TO 3.1.02 DRIVER ON SQLCOLATTRIBUTE CALL

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

Version 3.1.0.3

• 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 3.1.0.3.

• DBKEY IS NOT SHOWN CORRECTLY AFTER UPGRADED ODBC DRIVER FOR RDB 3.1.0.2 FROM 2.1

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

Version 3.1.0.2

• 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 3.1.0.2.

• 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 3.1.0.2.

Version 3.1.0.1

• 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 3.1.0.1, we terminate zero length varchars at the first character position to avoid inserting invalid data. Bug # 2258990. Fixed in 3.1.0.1.

• 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 3.1.0.1.

• 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 3.1.0.1.

• 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 3.1.0.1.

• 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 3.1.0.1.

• 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 3.1.0.1.

• 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 3.1.0.1.

• 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 3.1.0.1, 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 3.1.0.1

• 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 3.1.0.1, 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 3.1.0.1. Bug # 3713878

Version 3.1.0.0

• 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 3.1.0.0.

• 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 3.1.0.0.

• 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 3.1.0.0 (Bug 3069180)

• HELP button fixed

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

• 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 3.1.0.0

• General Error after SQLFreeStmt

Certain varieties of SQLFreeStmt calls did not clean up completely. Fixed in 3.1.0.0 (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 3.1.0.0 (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)

Version 3.0.2.6

• 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 3.0.2.6

• 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 3.0.2.6.

• 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 3.0.2.6.

• 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 3.0.2.6. 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 3.0.2.6.

• 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 3.0.2.6.

Version 3.0.2.5

• 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 3.0.2.5.

• 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 3.0.2.5.

• 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.

Version 3.0.2.4

• 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 3.0.2.4.

Version 3.0.2.3

• 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 3.0.2.3.

Version 3.0.2.2

• 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 3.0.2.0, broken again in 3.0.2.1, now fixed again in 3.0.2.2. 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.

Version 3.0.2.1

• 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 3.0.2.1.

• 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 3.0.2.1.

• 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 3.0.2.1.

• 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 3.0.2.1.

• "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 3.0.2.1.

• 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 3.0.2.1.

• 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 3.0.2.1.

• 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 3.0.2.1.

Version 3.0.2.0

• 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 3.0.2.0.

• 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 3.0.2.0.

• 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 3.0.2.0.

• 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 3.0.2.0.

·         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 3.0.2.0.

Version 3.0.1.3

• 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 3.0.1.3.

• 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 3.0.1.3.

• SQLProcedureColumns not returning all columns

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

Version 3.0.1.2

• SQLColAttribute returns null column name

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

• 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.

Version 3.0.1.1

• SQLTables returned no tables

The 3.0.1.0 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 3.0.1.0 release installed the HELP files with the wrong filenames. Fixed.

Version 3.0.1.0

• 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.

Version 3.0.0.5

• 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 3.0.0.4 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.

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.

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

SELECT LAST_NAME, DBKEY AS FOO FROM EMPLOYEES;

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

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.