Oracle ODBC Driver for Rdb Version 2.10.13 Release Notes Copyright 1993,1997 Oracle Corporation. All Rights Reserved. This file contains the following sections: 1. Installation 2. Post-Installation 3. Hardware Required 4. Software Required 5. Functionality 6. New Features 7. Information for Oracle Developer/2000 8. Information for Microsoft Access(R) Users 9. Information for Powersoft PowerBuilder(TM) Users 10. Data Conversions 11. Software Errors Fixed 12. Known Software Problems 13. Network Communications 1. Installation Oracle installer installs the Oracle ODBC Driver for Rdb software for the MS Windows, Windows NT and Windows 95 operating systems. The 16-bit driver may be installed under Microsoft Windows, Microsoft Windows NT or Microsoft Windows 95. The 32-bit driver can only be installed under Microsoft Windows NT and Microsoft Windows 95. Refer to the Oracle ODBC Driver for Rdb help file section entitled Post-Installation information for a list of files installed on your system. Refer to README.TXT enclosed in your software distribution kit for additional installation information. Note, version 2.10.12 was the last version containing updates to the 16-bit ODBC Driver for Rdb. Version 2.10.13 will be the last version to ship the 16-bit ODBC driver for Rdb. 2. Post-Installation A. Ensure that only one copy of sqsapiw.dll and/or sqsapi32.dll exists on your personal computer. The Oracle ODBC Driver for Rdb will not run with old versions of sqsapiw.dll or sqsapi32.dll. B. Use the Microsoft(R) ODBC Administrator to configure your Oracle ODBC Driver for Rdb data sources. C. If you are upgrading from the DEC ODBC Driver to the Oracle ODBC Driver for Rdb refer to the Oracle ODBC Driver for Rdb help file section entitled Post-Installation information. D. Along with the Oracle ODBC Driver for Rdb for Intel platforms, we install the Oracle ODBC Test tool. This tool was developed for the Oracle ODBC Driver and not for Rdb, so does not work in all cases with Rdb. The test tool was provided only as a simple means of testing connectivity between the Oracle ODBC Driver for Rdb and SQL/Services and Rdb running on a server system. 3. Hardware Required Refer to PRODDESC.TXT enclosed in your software distribution kit. 4. Software Required Refer to PRODDESC.TXT enclosed in your software distribution kit. 5. Functionality Refer to PRODDESC.TXT enclosed in your software distribution kit. 6. New Features Refer to the Oracle ODBC Driver for Rdb help file section entitled New Features for V2.1. The following new feature was added to V2.10.13: o Support for the use of data source file DSN's. NOTE: See note #11 below for information on changing connect attributes of the file DSN which can not be set at the time the file DSN is created. 7. Information for Oracle Developer/2000 Refer to the Acrobat RDBINFO.PDF document supplied with Developer/2000. 8. Information for Microsoft Access(R) Users A. The speed of the Microsoft Access "Attach Table..." option can be somewhat improved by specifying the following in the ODBC section of the msaccess.ini file (Microsoft Access V1.1 or V2.0 only): [ODBC] AttachableObjects='TABLE','VIEW' B. Note that changes to Oracle Rdb metadata (such as creating a unique index or altering a table) or changes made to the data source via the ODBC Administrator are not detected by Microsoft Access unless a new "Attach Table..." operation is performed. C. The fetch ahead feature within the Oracle ODBC Driver for Rdb is disabled when the hold cursor option is enabled for an Oracle Rdb Data Source. 9. Information for Powersoft PowerBuilder(TM) Users A. The following may be added to the [Rdb_SYNTAX] section of the pbodbxxx.ini file (where xxx = your Powerbuilder version): AlterForeignKey='ALTER TABLE &TableName ADD CONSTRAINT FOREIGN KEY (&ColumnName[,&ColumnName]...) REFERENCES &RefTableName CONSTRAINT &KeyName' AlterPrimaryKey='ALTER TABLE &TableName ADD CONSTRAINT PRIMARY KEY (&ColumnName[,&ColumnName]...)' CreatePrimaryKey=', PRIMARY KEY (&ColumnName[,&ColumnName]...)' CreateForeignKey=', CONSTRAINT &KeyName FOREIGN KEY (&ColumnName[,&ColumnName]...) REFERENCES &RefTableName' PBSelectProcSyntax='SELECT rdb$routine_source FROM rdb$routines WHERE rdb$routine_name = ''&ObjectName'' ' PBSelectViewSyntax='select rdb$view_source from rdb$relations where rdb$relation_name = ''&ObjectName'' ' B. The following two lines may be added to the [Rdb_SYNTAX] section of the PBODB030.INI file for users running PowerBuilder 3.0A: DropForeignKey='ALTER TABLE &TableName DROP CONSTRAINT &KeyName' PBFKeyListSyntax='SELECT DISTINCT '''',i.rdb$relation_name,f.rdb$field_name,f.rdb$field_position,1,1,f.rdb$constraint_name FROM rdbvms$relation_constraints c,rdbvms$relation_constraint_flds f,rdbvms$interrelations i WHERE f.rdb$field_position IN (SELECT Note that if the above lines are added, then you must add the following line to the [Rdb] section of the PBODB030.INI file: PBTrimCharColumns='YES' C. Executing Rdb Stored Procedures from Powerbuilder V3.0 Powerbuilder V3.0 does not support stored procedures that return output parameters. In order to execute Rdb stored procedures from Powerbuilder: 1. Add the following line to the Oracle ODBC Driver for Rdb section of the WIN.INI file: ProcOutParms=NO 2. Ensure that any stored procedures that are to be executed from Powerbuilder contain only INPUT and/or OUTPUT parameters and no INOUT parameters. 3. Use the Powerbuilder OUTPUT keyword in place of any output parameters in the stored procedure interactive execute statement or script declare statement. The following is an example of executing a procedure from the Powerbuilder Database Administration window that contains a character input, a numeric input, and one output: EXECUTE proc1 'Smith' , 42 , OUTPUT ; The following is an example of executing the same procedure from a PowerBuilder script: string name = "Smith"; int id = 42; string result; DECLARE myproc PROCEDURE FOR proc1 :name, :id, OUTPUT USING SQLCA ; EXECUTE proc1 ; FETCH proc1 INTO :result ; D. The following keywords are incorrect in the [Rdb_SYNTAX] section of the PBODB040.INI file for users running PowerBuilder 4.0: DropForeignKey= CreateForeignKey= PBFKeyListSyntax= Replace with the following: DropForeignKey='ALTER TABLE &TableName DROP CONSTRAINT &KeyName' CreateForeignKey=', CONSTRAINT &KeyName FOREIGN KEY (&ColumnName[,&ColumnName]...) REFERENCES &RefTableName' PBFKeyListSyntax='SELECT DISTINCT '''',i.rdb$relation_name,f.rdb$field_name,f.rdb$field_position,1,1,f.rdb$constraint_name FROM rdbvms$relation_constraints c,rdbvms$relation_constraint_flds f,rdbvms$interrelations i WHERE f.rdb$field_position IN (SELECT 10. Data Conversions The Oracle ODBC Driver for Rdb follows the Microsoft(R) ODBC 2.01 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 this 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 DOS Platform the number will drop precision to 123.99910293821 This loss of precision may have different behavior for different applications. For Microsoft Access(R), the user is not allowed to update the data. Microsoft Access(R) thinks the data has changed, because Oracle Rdb has the value 123.9991029382123 and Microsoft Access(R) now has the original but truncated number 123.99910293821. Microsoft Access(R) 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(R) the number is displayed as -1.123400000000000E-00 Microsoft Query(R) 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. 11. 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 atrributes, 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". 12. Software Errors Fixed SQLSpecialColumns Returned DBKEYS for tables that did not have DBKEYS. For example Oracle Rdb views are tables that do not contain DBKEYS. Problem has been fixed in version 2.0. SQLExecute and SQLExecDirect When Auto-commit on and a SQL Statement containing no outstanding transaction (ie. DISCONNECT ALL) was executed the following error message was returned: %SQL-F-NOIMPTXN, no implicit transaction to commit or rollback This error was only returned with Oracle SQL/Services Server greater than or equal to V6.1. Problem has been fixed in version 2.0.12. SQLForeignKeys Tables with more than one foreign key containing multiple columns comprising the foreign key constraint returned the following error status: %RDB-E-MULTIPLE_MATCH, record selection criteria should identify; more than one record found Problem has been fixed in version 2.0.12. SQLGetTypeInfo Wrong data values returned in SQLFetch or SQLGetData after SQL_TIMESTAMP or SQL_VARCHAR were given as the input (fSqlType) parameter. SQL_TIMESTAMP returned DATE and SQL_VARCHAR returned TIMESTAMP data. Problem has been fixed in version 2.0.12. SQLGetTypeInfo NULL Data not returned in SQLFetch or SQLGetData after SQL_ALL_TYPES was given as the input (fSqlType) parameter. LITERAL_PREFIX, LITERAL_SUFFIX, CREATE_PARAMS, UNSIGNED_ATTRIBUTE, AUTO_INCREMENT, MINIMUM_SCALE and MAXIMUM_SCALE will now return NULL Data when applicable. Not returning NULL data created a problem for Microsoft Query(R) applications, where user's were unable to re-edit selection queries containing more than one criteria. Problem has been fixed in version 2.0.13. SQLExecDirect,SQLExecute A incorrect status of SQL_SUCCESS was returned during a update or delete operation when no rows in the associated table had been modified. The correct status of SQL_SUCCESS_WITH_INFO is now returned to the calling application. SQLExecDirect will now release locks applied by the database when no rows in the table are updated. Problem has been fixed in version 2.0.14. SQLExecDirect,SQLPrepare The ABS(numeric_exp) scalar function failed when the numeric expression was a negative value. Problem has been fixed in version 2.0.15. SQLPutData A function sequence error occur when trying to update or insert a binary object (ie. images). This problem only occurred in version 2.0.14 of the Oracle ODBC Driver for Rdb. Problem has been fixed in version 2.0.15. SQLExecDirect,SQLPrepare An application calling a store procedure without any parameters would fail on a SQL syntax error if the procedure name was not followed by two parenthesis. Problem has been fixed in version 2.0.16. SQLProcedureColumns An application passing the like search pattern ie. "%" in the parameter szColumnName caused a general protection fault in SQRDB.DLL or SQRDB32.DLL when the procedure name passed via the szProcName parameter was to long. Problem has been fixed in version 2.0.16. SQLExecute and SQLExecDirect Failed transactions were not always notified as an error to the calling application. This problem was introduced in Oracle Rdb 6.0A eco02 when a second update is executed with no transaction outstanding. Normally, SQL would start an implicit transaction for this. The implicit transaction doesn't seem to be started in some cases. When this happens, Oracle Rdb returns %RDB-E-REQ_NO_TRANS on a SQLExecute or SQLExecDirect. SQL returns this as a -1005 error. The 2.0.17 Oracle ODBC Driver for Rdb assumes that -1005 errors are due to the SQL/Services server doing an auto commit when there was no transaction outstanding. This isn't really a problem, so these errors are not reported to the application. Because 6.0A eco02 SQL returns %RDB-E-REQ_NO_TRANS with a -1005 error number, the Oracle ODBC Driver for Rdb could not make the distinction between the internal error and the harmless error during autocommit. The Driver therefore failed to report the %RDB-E-REQ_NO_TRANS problem. In 2.0.18 of the Oracle ODBC Driver for Rdb we ignore the returned status and now check the error text rather than the SQL error code as a work around to this problem. Since the error text will be the text associated with the %RDB-E-REQ_NO_TRANS error, this will at least notify the calling application that the transaction was unsuccessful. Oracle Rdb will fix the following problems in future ECOs: - an implicit transaction will be started when needed so the %RDB-E-REQ_NO_TRANS should not occur on a second update with no explicit transaction outstanding - %RDB-E-REQ_NO_TRANS will be returned as -1 instead of -1005 Data Source Configuration Utility A Data Source Name (DSN) containing parenthesis could be added however, a DSN containing parenthesis could not be modified or deleted. The data source configuration utlility will now validate the DSN and disallow parenthesis as a valid character. Problem has been fixed in version 2.0.19. SQLExecDirect,SQLPrepare The CONCAT scalar function failed when a comma was inserted between a quoted string. Problem has been fixed in version 2.0.20. SQLExecute and SQLExecDirect Integer Data was truncated during an update or insert operation for some applications. This problem only occurred in version 2.0.19 of the Oracle ODBC Driver for Rdb. Problem has been fixed in version 2.0.20. SQLExecDirect 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 targetted 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. A problem in versions 2.0.20 and earlier of the Oracle ODBC driver occured if the first prepare using VMS format dates succeeded, but the subsequent execution failed, perhaps because of a lock time-out, constraint failure, or other error. In this case, the driver would incorrectly try to re-prepare the request using ANSI format dates. However, this prepare would then fail with a "%SQL-F-UNSDATASS, Unsupported date/time assignment from to " error and the original error would be lost. Problem has been fixed in version 2.0.21. SQLExecute and SQLExecDirect Real Data stored in Oracle Rdb lost precision and was rounded during an update or insert operation. This problem would only occur when the precision of the number was greater than 7. Problem has been fixed in version 2.10.11 SQLColumns, SQLExecute and SQLExecDirect In the 32 bit versions of the Oracle ODBC Driver for Rdb, the DATA_TYPE column name in SQLColumns was incorrectly converting negative numbers to a character data types after a call to SQLFetch or SQLGetData. For example, if you retrieved a column whose data type was BIGINT the DATA_TYPE field should return a -5 instead the driver returned 65531. This problem showed up in some applications when converting negative numbers to a character data types for tiny and small integers. Oracle Rdb would return a the following error message when updating the data. %RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime -COSI-F-INTOVF, integer overflow Problem has been fixed in version 2.10.11. SQLState 08S01 Previous versions of the Oracle ODBC Driver for Rdb used to return the following error when the connection with the server was lost: SQLState = S1000 Native error code :-2003 when it should have returned SQLState = 08S01 (communication link failure) Problem has been fixed in version 2.10.12. SQLProcedureColumns Previous versions of the Oracle ODBC Driver for Rdb returned information about parameters of a stored procedure out of order. This made it impossible for the calling application to determine what order to pass parameters to a stored procedure. Problem has been fixed in version 2.10.12. SQL/Services Winsock Logging With SQL/Services winsock logging enabled, certain applications used to generate invalid page faults in SQSAPI32.DLL on application shutdown. Problem has been fixed in version 2.10.12. 13. Known Software Problems 1) Any application that has upgraded from the DEC ODBC Driver to the Oracle ODBC Driver for Rdb and is using the following keyword in SQLDriverConnect DRIVER={DEC ODBC Driver}; This keyword will no longer work and the following message will be returned from the ODBC Driver manager. "[Microsoft][ODBC DLL]Data source name not found and no default driver specified" To fix the problem the DRIVER keyword must look like the following: DRIVER={Oracle ODBC Driver for Rdb}; 2) The following error occurs when trying to access and ODBC data source from a 32-bit application under Win32s: Attempt to load required component ODBC32.DLL failed. or The Initialization of a dynamic link library failed. process is terminated abnormally. Win32s - Error Unexpected Error: 21 There are two main causes for this: - The ODBC components were not installed because the ODBC setup program was not executed. - The incorrect version of the ODBC32.DLL file (the thunking driver manager) has been installed. To fix the problem, remove or rename ODBC32.DLL located in the \WINDOWS\SYSTEM directory and reinstall the Oracle ODBC Driver for Rdb. 3) 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. 4) 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 targetted 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. 14. Network Communications The Oracle ODBC Driver for Rdb uses the Oracle SQL/Services client (sqsapiw.dll or sqsapi32.dll) for all network communications. This file documents the network features of the Oracle SQL/Services client. 1. NetWare Support o Oracle SQL/Services client supports NetWare NOTE: To use NetWare with ODBC, you must be running the 16-bit version of the client against a server with one of the following configurations: - OpenVMS VAX Oracle SQL/Services V6.1 or higher - OpenVMS Alpha Oracle SQL/Services V6.1 or higher The Oracle SQL/Services Dynamic Link Library (DLL) contains support for Novell's IPX/SPX transport and NetWare Services. The Oracle SQL/Services client supports NetWare in Oracle SQL/Services V6.x. With this support comes the following features for the Oracle SQL/Services client: - Support for the Oracle SQL/Services client requires the following: * Novell NetWare 3.11 Windows Workstation Client * ipx.com or ipxodi.com * netx Shell * NetWare 'C' Interface for Windows (Version:Update 7) as implemented in the nwipxspx.dll and nwnetapi.dll (DLLs). (These DLLs are shipped with the Oracle SQL/Services client and the Oracle ODBC Driver for Rdb). * sqsapiw.ini See Section 3 for more information about this file. o Oracle SQL/Services client supports MS Windows standard mode The Oracle SQL/Services client now supports Windows standard mode. This support requires Novell's tbmi2.com TSR file. The tbmi2.com file must be loaded to perform task switching buffer management. Oracle recommends that you create a .BAT file, such as RUNWIN.BAT, for starting MS Windows that contains the following commands: REM runwin.bat REM LOAD TBMI2 tbmi2 REM START WINDOWS win REM UNLOAD TBMI2 ON EXIT FROM WINDOWS tbmi2 \u o Configuring the Oracle SQL/Services client for NetWare support The following steps are used to select and configure the Oracle SQL/Services client for NetWare support: - Novell's IPX/SPX uses File server names in place of node names. A File server name must be specified in the ODBC Administrator instead of an OpenVMS node name. The maximum length of the server name is 48 bytes, as specified by Novell. The Oracle SQL/Services server requires this server name to be the name of the Interconnections File Server located physically on the same node as the Oracle SQL/Services server. The Oracle SQL/Services server requires an Interconnections File Server to be installed and running. The Oracle SQL/Services client uses the Interconnections File Server as a name server. These names are case sensitive. - The Oracle SQL/Services client supports two methods of specifying the File Server's address. 1. Using the sqsapiw.ini file You can specify the file server's information in the sqsapiw.ini file, for example, as follows: [Server Name] ;Interconnections FSS Server Name located ;on same node as the Oracle SQL/Services ;Server. Transport=IPX/SPX ;Specify transport type for above server IPXInetAddress=0063380 ;Specify File Server's network address IPXHostAddress=AA-00-04-00-54-7C ;Specify File Server's Host Address See Section 3 for more information about the sqsapiw.ini file. 2. In the ODBC Administrator, specify the file server name in place of the node name. The nearest file server will be queried to provide the client with the address of the specified file server. This option is slightly slower than the sqsapiw.ini method, but is easier to manage. If the sqsapiw.ini file has a valid entry, that will override the querying of the server. These names are case sensitive. 2. Windows Sockets Support NOTE: To use Windows Sockets support, you must use either the V5.1x, V6.0x, V6.1x or V7.0x Oracle SQL/Services server. "Windows Sockets is a specification that defines a network programming interface for Microsoft Windows which is based on the 'socket' paradigm popularized in the Berkeley Software Distribution (BSD) from the University of California at Berkeley. It encompasses both familiar socket style routines and a set of MS Windows-specific extensions designed to allow the programmer to take advantage of the message-driven nature of MS Windows." "Windows Sockets is an independent specification which was created and exists for the benefit of application developers and network vendors, and indirectly, computer users." The information in these first two paragraphs is cited from Windows Sockets An Open Interface for Network Programming Under Microsoft Windows by Martin Hall, Mark Towfig, Geoff Arnold, David Treadwell, and Henry Sanders, V1.1 20 January 1993. 130pp. The Oracle ODBC Driver for Rdb can use any Windows Sockets V1.1 specification compliant transport. Oracle SQL/Services provides additional logging capability for WINSOCK. This can be enabled by uncommenting the line: WinSockLogging=1 3. sqsapiw.ini or sqsapi32.ini File The sqsapiw.ini or sqsapi32.ini file contains optional configuration information that overrides previously set parameters. The following parameters can be overriden when set in the sqsapiw.ini or sqsapi32.ini file: o Transport type as set using the ODBC Administrator o Client logging as set in the Oracle ODBC Driver for Rdb section of the win.ini or rdbodbc.ini file. o Server configuration information for IPX/SPX, such as, the server name that is specified in the ODBC Administrator. 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. The concept of specifying the Interconnections file server, transport type, file server's node address, and file server's internal network number is similar to that of the TCP/IP hosts file. This method can also be used to create an alias for the IPX/SPX server names. 4. Unable to install NetWare DLL's Installation Error The nwipxspx.dll and nwnetapi.dll files are the Novell's NetWare C Interface DLLs that Oracle has permission to redistribute. If you already have these DLLs installed on your system, you need to check the date and version of these installed files to determine if they are more recent than the ones provided in this kit. If the installed files are more recent, then use the previously installed files. If the installed files are older than the ones provided on this kit, you must replace them. **************************************************************************** Oracle is a registered trademark of Oracle Corporation. Oracle, SQL*Net is a registered trademark of Oracle Corporation. Microsoft Access, Microsoft Query, Microsoft, MS are registered trademarks of Microsoft Corporation. Microsoft Windows, Windows NT, Windows 95 and Open Database Connectivity are trademarks of Microsoft Corporation. NetWare is a registered trademark of Novell. PowerBuilder is trademark of Powersoft Corporation. InterConnections and File Sharing Services are trademarks of InterConnections, Inc. Leverage is a registered trademark of InterConnections Inc. The DIGITAL Logo, Alpha, DEC, DECnet, Digital, OpenVMS, PATHWORKS, VAX are trademarks of Digital Equipment Corporation. Intel is a registered trademark of Intel Corporation. All other trademarks and registered trademarks are the property of their respective owners. ****************************************************************************