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

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.

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]".

The Oracle ODBC Driver for Rdb requires a system configuration supported by Microsoft Windows 2000/XP/2003/Vista/2008/Windows 7 including:

• A minimum of 8 MB system memory
• A minimum of 2.0MB free disk space
• Networking hardware and software
• An Intel "386" or equivalent architecture CPU

Client Software Requirements

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

• Microsoft Windows 2000 Operating System
• Microsoft Windows XP Operating System
• Microsoft Windows 2003 Operating System
• Microsoft Windows Vista Operating System
• Microsoft Windows 2008 Operating System
• Microsoft Windows 7 Operating System
  

For DECnet transport, the same software requirements as for TCP/IP plus the following:

• PATHWORKS32 v7.0A

Server Software Requirements

This section lists the software required to support the Oracle ODBC Driver for Rdb on OpenVMS VAX and Alpha platforms.

• Oracle SQL/Services and Oracle Rdb for OpenVMS - V6.1 or later
• One of the following network transport options:
• • DECnet transport - DECnet for OpenVMS
  • TCP/IP transport - DEC TCP/IP Services for OpenVMS

NOTE: See Oracle SQL/Services release notes for specific software versions and OpenVMS version prerequisites.

The Oracle ODBC Driver for Rdb supports SQL-92 compliant Oracle Rdb SQL. DECnet and TCP/IP network transports are supported. Online documentation is provided via the Microsoft Windows Help facility.

The Oracle ODBC Driver for Rdb complies with Version 3.0 of the Microsoft ODBC specification and supports all ODBC Core and Level 1 calls and the following Level 2 calls:

• SQLDataSources
• SQLDescribeParam
• SQLDrivers
• SQLExtendedFetch
• SQLForeignKeys
• SQLMoreResults
• SQLNativeSql
• SQLNumParams
• SQLParamOptions
• SQLPrimaryKeys
• SQLProcedureColumns
• SQLProcedures
• SQLSetScrollOptions

The following ODBC API level 2 functions are not supported:

• SQLTablePrivileges
• SQLSetPos
• SQLColumnPrivileges

Additional features include but are not limited to:

• Support for Version 3.0 of the Microsoft ODBC specification.
• Support for Oracle Rdb Hold Cursors.
• Support is added for the proxy access feature to avoid prompting for password information when using the SQLDriverConnect call.
• The Oracle ODBC Driver for Rdb is Thread Safe.

Refer to the Acrobat RDBINFO.PDF document supplied with Developer/2000.

The Oracle ODBC Driver for Rdb follows the Microsoft ODBC 3.0 Software Development Kit (SDK) guidelines for manipulating and displaying real and double data types. Precision (the maximum number of digits used) of SQL_DOUBLE and SQL_FLOAT data types is 15.

If double values are stored in a Oracle Rdb database precision for these data types can be much greater than what ODBC currently supports. The end result will be the loss of precision. For Example:

A float data type defined in Rdb with the default precision contains a number such as:

123.9991029382123

When converted on the Windows platform the number will drop precision to

123.99910293821

This loss of precision may have different behavior for different applications. For Microsoft Access, the user is not allowed to update the data. Microsoft Access thinks the data has changed, because Oracle Rdb has the value 123.9991029382123 and Microsoft Access now has the original but truncated number 123.99910293821. Microsoft Access cannot update the row using the 123.99910293821 truncated number as a selection criteria since that row does not exist in the Oracle Rdb database. Only the original row with 123.9991029382123 exists in the Oracle Rdb database.

One workaround to the problem is to define the data type in Oracle Rdb as BIGINT (13) or whatever is appropriate for your application. Microsoft Access(R) will see BIGINT data types as text fields and allow you to update the row without losing precision.

In Microsoft Query(R) the display will be incorrect. Lets take for example the following double precision number to display:

-1.123400000000000E-001

with Microsoft Query the number is displayed as

-1.123400000000000E-00

Microsoft Query makes a call to SQLColAttributes returning the display size of 22. The format defined in the ODBC SDK for display of a double precision data is the following:

Total 22 Length (a sign,15 digits,a decimal point,the letter E, a sign and 3 digits)

Our example contains a total string length of 23 with 16 digits instead of the 15 digits for precision. This is why the data is displayed wrong. One possible workaround to this problem may be to add a text field that is computed by the cast of the double precision field within Oracle Rdb. Then display the text field instead of the double.

$ SQL > alter table dbl_tab add dbltxt computed by cast (dbl as char(23));

When a file DSN is set up, not all connect attributes are obtained. Default values are used for those values the data source administrator does not prompt for. To change those defaulted connect attributes, edit the file DSN which will be created in the c:\Program Files\Common Files\ODBC\Data Sources directory.

Refer to the Oracle ODBC Driver for Rdb help file for a complete description of the attributes listed in the file DSN. The information can be found under the topic "Format of the Connection String" listed under the main heading of "Programming Considerations".

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.

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.

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

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

• 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

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

• 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

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

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

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

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

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

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

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

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

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

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

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

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

4. Unable to update through a Microsoft SQLServer 2008 linked table if the where clause contains a character column. This was caused by a change in behavior in the layers between Microsoft SQLServer and MSDASQL (Microsoft OLEdb Provider for ODBC). Microsoft is currently working to identify why this change in behavior occurred and how to remedy the situation.

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, 2010, 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.