print Printer View e-mail E-mail this page Bookmark Bookmark
Oracle ODBC Driver for Rdb, Release 3.2.0.0 for Windows
Skip Headers
Oracle ODBC Driver for Rdb® Release Notes
Release 3.3.0.0 for Microsoft Windows
 

Oracle ODBC Driver for Rdb®

Release Notes

Release 3.3.0.0 for Microsoft Windows

March 2009

This documentation contains information about the following topics:

1 Overview About This Release

This kit includes Version 3.3.0.0 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.

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 sqsapiw.dll and/or sqsapi32.dll exists on your computer. The Oracle ODBC Driver for Rdb will not run with old versions of sqsapiw.dll or sqsapi32.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 2000/XP/2003/Vista/2008 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

5 Software Required

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

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.

6 Functionality

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.

7 Information for Oracle Developer/2000

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

8 Data Conversions

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

In general to avoid precision problems using ODBC, ensure that data stored in the Oracle Rdb database for a double data type conform to the specifications described in the Microsoft ODBC Programmer's Reference and SDK Guide.

9 Changing connect attributes of File DSN's

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

10 New Features Implemented and Errors Fixed

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.

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.

  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.

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

 
 
E-mail this page
Printer View Printer View
Oracle Is The Information Company About Oracle | Oracle RSS Feeds | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy