Oracle ODBC Driver
for Rdb Release Notes, Release 3.0.1.2 for Windows
Copyright 1993,2001
Oracle Corporation. All Rights Reserved.
This file contains the following sections:
Information About This Release
This kit includes Version 3.0 of the Oracle ODBC Driver for Rdb.
This version is considerably different internally from the version 2
Oracle ODBC Driver for Rdb software.
Installation
This product is installed by the Oracle Universal Installer,
a completely different technology from that used by previous
releases of the Oracle ODBC Driver for RDB.
To assist those customers who do not already have the Universal
Installer, this kit is being made available in two forms, one
without the installer included (about 1 MB in size) and one with
the installer (about 12 MB in size). Both kits are distributed
on the web in the form of self-extracting ZIP archives.
To install the larger kit, run the SETUP.EXE in the top level ("Disk1")
of the expanded directory tree. This will start the Installer.
To install the smaller kit, run the Oracle Universal Installer
you already have on your system. When the installer starts,
click the NEXT button on the first screen. On the second screen,
use the BROWSE button to set the "source" to the "products.jar"
file inside the "STAGE" directory. (With the larger kit, this
will already be set correctly.)
Post-Installation
- 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.
- Use the Microsoft ODBC Administrator to configure your data sources. In a
change from previous 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.
- 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]".
Hardware Required Refer to PRODDESC3.TXT.
Software Required
Refer to PRODDESC3.TXT.
Functionality Refer to PRODDESC3.TXT.
New Features Refer to the Oracle ODBC Driver for Rdb help file section
entitled New Features for V3.0.
Information for Oracle Developer/2000 Refer to the Acrobat RDBINFO.PDF
document supplied with Developer/2000.
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:
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.
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".
Software Errors
Fixed
SQLColAttribute returns null column names
SQLColAttribute was returning a null string for the column name.
Problem 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.
Problem fixed in version 3.0.1.2
DBKEYs returned as binarys
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.
Problem fixed in version 3.0.1.2
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.
Problem fixed in version 3.0.1.1
HELP files installed under wrong name
The 3.0.1.0 release installed the HELP files with the wrong filenames.
Problem fixed in version 3.0.1.1
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.
Problem fixed in version 3.0.1.0
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.
Problem fixed in version 3.0.1.0
Kanji translator restored
The DLL that does translations between Latin and Japanese character
sets, DECKAN32.DLL, was missing from previous beta releases.
Problem fixed in version 3.0.0.5
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.
Problem fixed in version 3.0.0.5
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.
Problem fixed in version 3.0.0.5
SQLGetTypeInfo, SQLColumns, SQLTables, and SQLDescribeCol
Metadata queries using these functions did not return consistent results
and in some cases returned completely incorrect results.
Problem fixed in version 3.0.0.5
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.
This has been fixed in version 3.0.0.5
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.
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.
Problem has been fixed in version 2.10.16 and 3.0.0.5
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.
Problem has been fixed in version 3.0.0.5
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.
Problem has been fixed in version 2.10.18 and 3.0.0.5
Known Software
Problems
- 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.
- 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.
- 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.
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 rdbodbc.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 © 1993, 2001, Oracle Corporation. All Rights Reserved.
The Programs (which include both the software and documentation) contain
proprietary information of Oracle Corporation; they are provided under a
license agreement containing restrictions on use and disclosure and are also
protected by copyright, patent, and other intellectual and industrial
property laws. Reverse engineering, disassembly, or decompilation of the
Programs is prohibited.
The information contained in this document is subject to change without
notice. If you find any problems in the documentation, please report them to
us in writing. Oracle Corporation does not warrant that this document is
error free. Except as may be expressly permitted in your license agreement
for these Programs, no part of these Programs may be reproduced or
transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Oracle Corporation.
If the Programs are delivered to the U.S. Government or anyone licensing or
using the programs on behalf of the U.S. Government, the following notice is
applicable:
Restricted Rights Notice Programs delivered subject to the DOD FAR
Supplement are "commercial computer software" and use, duplication, and
disclosure of the Programs, including documentation, shall be subject to the
licensing restrictions set forth in the applicable Oracle license agreement.
Otherwise, Programs delivered subject to the Federal Acquisition Regulations
are "restricted computer software" and use, duplication, and disclosure of
the Programs shall be subject to the restrictions in FAR 52.227-19,
Commercial Computer Software - Restricted Rights (June, 1987). Oracle
Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
The Programs are not intended for use in any nuclear, aviation, mass transit,
medical, or other inherently dangerous applications. It shall be the
licensee's responsibility to take all appropriate fail-safe, backup,
redundancy, and other measures to ensure the safe use of such applications if
the Programs are used for such purposes, and Oracle Corporation disclaims
liability for any damages caused by such use of the Programs.
Oracle is a registered trademark, and Oracle Rdb, Oracle SQL/Services, and are
trademarks or registered trademarks of Oracle Corporation. Other names may be
trademarks of their respective owners.
[Oracle]
Copyright © 1993, 2001 Oracle Corporation.
All Rights Reserved.
| 
Bookmark
