Oracle_Rdb7[TM]_____________________________________ Oracle SQL/Services[TM] Release Notes Release 7.0 ________________________________________________________________ Oracle SQL/Services Release Notes Release 7.0 Copyright © 1993, 1996 Oracle Corporation. All rights reserved. This software contains proprietary information of Oracle Corporation; it is provided under a license agreement containing restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software 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. Restricted Rights Legend Programs delivered subject to the DOD FAR Supplement are 'commercial computer software' and use, duplication and disclosure of the programs 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-14, Rights_in_Data-General, including Alternate III (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, back up, redundancy and other measures to ensure the safe use of such applications if the programs are used for such purposes, and Oracle disclaims liability for any damages caused by such use of the programs. Oracle and SQL*Net are registered trademarks of Oracle Corporation, Redwood City, California. Rdb7, Oracle Rdb, DBAPack, Oracle Network Manager, Oracle7, and Oracle SQL/Services are trademarks of Oracle Corporation, Redwood City, California. All other products or company names are used for identification purposes only and may be trademarks of their respective owners. _________________________________________________________________ Contents Send Us Your Comments..................................... v Preface................................................... vii 1 Oracle SQL/Services: New and Changed Features 1.1 Installing Oracle SQL/Services V7.0........... 1-1 1.1.1 Oracle SQL/Services Installation Changes................................... 1-1 1.1.2 Oracle SQL/Services Software Requirements and Compatibility Information for V7.0.... 1-4 1.1.3 Contents of the Oracle SQL/Services Client Kits on CD-ROM............................ 1-4 1.2 Summary of Oracle SQL/Services New and Changed Features for V7.0............................. 1-5 1.3 Using SQL*Net as a Network Transport in Oracle SQL/Services V7.0............................. 1-20 1.3.1 New Concepts or New Terminology........... 1-21 1.3.2 Oracle SQL/Services Client API............ 1-22 1.3.3 Oracle SQL/Services Server Configuration............................. 1-23 1.3.4 Oracle Network Manager.................... 1-23 1.3.5 Creating Oracle Network Manager Configuration Files....................... 1-24 1.3.6 Distributing Oracle Network Manager Configuration Files....................... 1-26 1.3.7 SQL*Net Network Tracing and Logging Files..................................... 1-26 1.4 Deprecated Features........................... 1-26 1.5 Obsolete Features............................. 1-29 iii 2 Software Errors Fixed 2.1 Oracle SQL/Services Server Errors Fixed for V7.0.......................................... 2-1 2.1.1 Problems Fixed in the Oracle SQL/Services V7.0 Server............................... 2-1 2.1.2 Problems Fixed in Oracle SQL/Services V7.0 Clients................................... 2-11 3 Known Problems, Restrictions, and Other Notes 3.1 Oracle SQL/Services Known Problems and Restrictions for V7.0......................... 3-1 3.1.1 Oracle SQL/Services Manager GUI Restrictions and Known Problems........... 3-1 3.1.2 Oracle SQL/Services V7.0 Server Restrictions and Known Problems........... 3-2 3.1.3 Oracle SQL/Services V7.0 Client Restrictions and Known Problems........... 3-12 3.1.4 Other Oracle SQL/Services Server for OpenVMS and Digital UNIX Restrictions and Known Problems............................ 3-15 3.1.5 Other Oracle SQL/Services Client Restrictions and Known Problems........... 3-22 3.1.6 Oracle SQL/Services Software Installation Requirement and Compatibility Information............................... 3-25 3.1.7 Oracle SQL/Services Documentation Errors or Omissions.............................. 3-35 Tables 3-1 Oracle SQL/Services on Digital UNIX Client/Network Support.................... 3-26 3-2 Oracle SQL/Services on OpenVMS Alpha Client/Network Support.................... 3-28 3-3 Oracle SQL/Services on OpenVMS VAX Client/Network Support................ 3-29 iv _________________________________________________________________ Send Us Your Comments Oracle Corporation welcomes your comments and suggestions on the quality and usefulness of this publication. Your input is an important part of the information used for revision. You can send comments to us in the following ways: o Electronic mail - nedc_doc@us.oracle.com o FAX - 603-881-0120 Attn: Oracle Rdb Documentation o Postal service Oracle Corporation Oracle Rdb Documentation 110 Spit Brook Road, ZKO2-1/O19 Nashua, NH 03062-2698 USA If you like, you can use the following questionnaire to give us feedback. (Edit the online release notes file, extract a copy of this questionnaire, and send it to us.) Name Title _____________________________ ________________________ Company Department _____________________________ ________________________ Mailing Address Telephone Number _____________________________ ____________ __________________________________________________________ Book Title Version Number _____________________________ ____________ v o Did you find any errors? o Is the information clearly presented? o Do you need more information? If so, where? o Are the examples correct? Do you need more examples? o What features did you like most about this manual? If you find any errors or have any other suggestions for improvement, please indicate the chapter, section, and page number (if available). vi _________________________________________________________________ Preface Oracle SQL/Services software is a client/server component of Oracle Rdb. Oracle SQL/Services lets you develop client application programs on a variety of desktop and mainframe systems so that you can access Oracle Rdb databases as well as other databases supported by the Oracle Rdb implementation of the SQL standard. Oracle ODBC Driver for Rdb is available for the following client operating systems: MS Windows, Windows 95, Windows NT X86, and Windows NT Alpha. The Oracle ODBC Driver for Rdb allows ODBC applications on these clients read and write access to Oracle Rdb databases using TCP/IP, DECnet, SQL*Net (for MS Windows clients only), or IPX/SPX transport (for MS Windows clients only). The Oracle ODBC Driver for Rdb uses Oracle SQL/Services software to access the data. This manual describes new and changed features; problems fixed in this release; and current problems, restrictions, and other notes. Intended Audience These release notes are intended for all users of Oracle SQL/Services and Oracle ODBC Driver for Rdb and should be read to supplement information contained in the Oracle SQL/Services Installation Guide, the Oracle SQL/Services Server Configuration Guide, the Guide to Using the Oracle SQL/Services Client API, and the Oracle ODBC Driver for Rdb help file. To get the most out of this manual, you should be familiar with Oracle SQL/Services, data processing procedures, and basic database management concepts and terminology. vii Operating System Information Information about the versions of the operating system and related software that are compatible with this version of Oracle SQL/Services and the Oracle ODBC Driver for Rdb is included in these release notes (see Section 3.1.6). Structure This manual contains three chapters: Chapter 1 Describes the new and changed features of Oracle SQL/Services V7.0. Chapter 2 Describes known software errors in versions prior to V7.0 of Oracle SQL/Services that were fixed in V7.0. Chapter 3 Describes problems, restrictions, and workarounds known to exist in Oracle SQL/Services. This chapter also includes restrictions retained from previous versions of Oracle SQL/Services and miscellaneous notes. Related Manuals For more information on Oracle Rdb and Oracle SQL/Services, see the other manuals in this documentation set, especially the following: o Oracle SQL/Services Installation Guide o Oracle SQL/Services Server Configuration Guide o Oracle Rdb7 Installation and Configuration Guide o Guide to Using the Oracle SQL/Services Client API For more information on the Oracle ODBC Driver for Rdb, see the README files and the Oracle ODBC Driver for Rdb help file. Oracle Rdb7 Release Notes provides descriptions of, and ordering information for all manuals in the Oracle Rdb documentation set. The Oracle SQL/Services Release Notes and the Oracle Rdb7 Release Notes are provided only as part of the software kit. PostScript (.ps) and text (.release_notes) files for the release notes are available in SYS$HELP. viii All other books are available in both Bookreader and printed form. Conventions In this manual, Oracle Rdb refers to Oracle Rdb for OpenVMS and Oracle Rdb for Digital UNIX software. Version 7.0 of Oracle Rdb software is often referred to as V7.0. The SQL interface to Oracle Rdb is referred to as SQL. This interface is the Oracle Rdb implementation of the SQL standard ANSI X3.135-1992, ISO 9075:1992, commonly referred to as the ANSI/ISO SQL standard or SQL92. Oracle ODBC Driver for Rdb software is referred to as the ODBC driver. OpenVMS means both the OpenVMS Alpha and the OpenVMS VAX operating system. In examples, an implied carriage return occurs at the end of each line, unless otherwise noted. You must press the Return key at the end of a line of input. Often in examples the prompts are not shown. Generally, they are shown where it is important to depict an interactive sequence exactly; otherwise, they are omitted in order to focus full attention on the statements or commands themselves. This manual uses icons to identify information specific to an operating system or platform. Where material pertains to more than one platform or operating system, combination icons or generic icons are used. For example: <> These icons do not appear in the text version of this document but are replaced by characters enclosed by angle brackets (<>). The following conventions are also used in this manual: ix [ ] In format descriptions, brackets enclose optional clauses from which you can choose one or none. In a prompt, brackets indicate that the enclosed item is the default response. For example, [y] means the default response is Yes. $ The dollar sign represents the DIGITAL Command Language prompt in OpenVMS and the Bourne shell prompt in Digital UNIX. # The number sign represents the Digital UNIX superuser account prompt. % The percent sign represents the Digital UNIX default user prompt. > The right angle bracket represents the MS-DOS command language prompt. boldface Boldface type in text indicates a term defined text in the text. x 1 _________________________________________________________________ Oracle SQL/Services: New and Changed Features This chapter describes the new features and technical changes to Oracle SQL/Services Version 7.0 and a summary of all changes in V7.0. In addition, it describes obsolete routines, structures, and features, and provides a summary of additions and changes to the documentation. 1.1 Installing Oracle SQL/Services V7.0 Refer to the Oracle SQL/Services Installation Guide for installation information. Section 1.1.1 briefly highlights the major changes to the Oracle SQL/Services installation procedure, which are described in detail in the Oracle SQL/Services Installation Guide. 1.1.1 Oracle SQL/Services Installation Changes The Oracle SQL/Services installation is changed in the following ways: o The Oracle SQL/Services server on the multiversion kit is now truly multiversioned on OpenVMS. Note that the OpenVMS client is always installed standard. You can install Oracle SQL/Services V7.0 as either multiversion or standard. Refer to the Oracle SQL/Services Installation Guide for more information. o New Oracle DBAPack for Rdb and Oracle SQL/Services clients and Oracle ODBC Driver for Rdb clients are available on the Oracle Rdb Client CD-ROM. The Oracle DBAPack for Rdb and all Oracle SQL/Services clients (except OpenVMS clients) and Oracle ODBC Driver for Rdb clients are available on the Oracle Rdb Client CD-ROM. Follow the installation instructions in the readme.txt file in the top-level directory of the CD-ROM. The Oracle DBAPack for Rdb includes Oracle SQL/Services: New and Changed Features 1-1 clients such as the Oracle Rdb Performance Monitor, the Oracle RMUwin, the Parallel Backup Monitor, the Query Performance Tuner, and the Oracle SQL/Services Manager. ________________________ Note ________________________ Oracle SQL/Services client kits (except the OpenVMS clients) are no longer available on the Oracle SQL/Services server kit. ______________________________________________________ The Oracle SQL/Services OpenVMS client kits ship on the same CD-ROM as the server kit. The Oracle SQL/Services SunOS client, ULTRIX for RISC client, and MS-DOS large memory model client are deprecated and frozen at the V6.1 level. See Section 1.4 for more information. o New sqlsrv$deinstall_delete procedure. In versions of Oracle SQL/Services prior to V7.0, the Oracle Rdb deinstall procedure deinstalled Oracle SQL/Services along with Oracle Rdb. Beginning with V7.0, Oracle SQL/Services is no longer deinstalled as part of the Oracle Rdb deinstall procedure. Oracle SQL/Services now provides a separate deinstall procedure, SYS$MANAGER:sqlsrv$deinstall_delete.com for deleting Oracle SQL/Services V5.1 and higher. For more information see the Oracle SQL/Services Installation Guide. o New Oracle SQL/Services configuration file conversion utility. There is now a conversion utility available that converts any Oracle SQL/Services V5.1, V6.0, or V6.1 configuration file into a V7.0 SQLSRV_MANAGE script file that you can run to add your previously defined classes to a V7.0 configuration file. The conversion utility is available on both OpenVMS Alpha and OpenVMS VAX platforms. See the Oracle SQL/Services Installation Guide for more information. o sqlsrv$shutdown and sqlsrv$shutdown70 procedures are in SYS$MANAGER. 1-2 Oracle SQL/Services: New and Changed Features The sqlsrv$shutdown.com and sqlsrv$shutdown70.com (for the multiversion kit) procedures, which used to be invoked with the SYS$STARTUP logical name, are now located in SYS$MANAGER. The procedures can still be invoked using SYS$STARTUP because this directory is in a search list. These procedures used to be in SYS$COMMON:[SYS$STARTUP] and are now in SYS$COMMON:[SYSMGR]. o Oracle SQL/Services installation optionally installs SQL*Net. The Oracle SQL/Services installation procedure optionally installs a version of SQL*Net that works with Oracle SQL/Services. Only Oracle SQL/Services clients and servers use this SQL*Net image. Installing the Oracle SQL/Services version of SQL*Net does not impact an existing SQL*Net installation. See Section 1.3 for updates to using SQL*Net as a transport type for Oracle SQL/Services V7.0. o Two new accounts are now created, the SQLSRV$DEFLT and RMU$SRV accounts, for which you will be requested to enter valid UICs and directory locations during installation. ________________________ Note ________________________ Beginning with Oracle SQL/Services V7.0, the SQLSRV$SRV and SQLSRV$SRVnn (for multiversion) accounts are no longer created. ______________________________________________________ o The installation installs the Japanese version of the Oracle SQL/Services message files, if applicable. The Oracle SQL/Services OpenVMS server kits will install a Japanese version of the Oracle SQL/Services message file on the system if the Japanese version of OpenVMS is installed. In order for Oracle SQL/Services to use the Japanese version of the Oracle SQL/Services message file, Oracle SQL/Services must be started with an optional parameter: @SYS$STARTUP:SQLSRV$STARTUP[70] J Oracle SQL/Services: New and Changed Features 1-3 If the optional parameter "J" is passed to the SQLSRV$STARTUP procedure, Oracle SQL/Services defines the SQLSRV_MESSAGES logical to point to the Japanese version of the message file. In addition, Oracle SQL/Services uses the Japanese version of Oracle Rdb, if any, for executor processes. 1.1.2 Oracle SQL/Services Software Requirements and Compatibility Information for V7.0 Software requirements and compatibility information for installing Oracle SQL/Services V7.0 can be found in Section 3.1.6. 1.1.3 Contents of the Oracle SQL/Services Client Kits on CD-ROM The following client kit changes were made for Oracle SQL/Services, beginning with Oracle SQL/Services V7.0. o Archive files are no longer shipping for most Oracle SQL/Services clients. The following Oracle SQL/Services client kits no longer ship as .tar or self extracting archive files. These Oracle SQL/Services clients ship on the CD-ROM as exploded client kits: - Sun Solaris client (for V2.4 of Solaris) - Digital UNIX client - All PC Windows clients The MAC clients continue to ship as self-extracting archive files on the CD-ROM. o Macintosh for THINK C installation changes. The Macintosh for THINK C installation is changed. THINK C V8 is now supported. Refer to the readme.txt file in the MAC directory on the Oracle Rdb Client CD-ROM for the most current Macintosh for THINK C client API installation information. 1-4 Oracle SQL/Services: New and Changed Features 1.2 Summary of Oracle SQL/Services New and Changed Features for V7.0 The following sections summarize and describe new and changed features for Oracle SQL/Services Version 7.0. New and Changed Server Features The following describes new and changed server features: o New Oracle SQL/Services server architecture on OpenVMS systems. Oracle SQL/Services uses a new server architecture on OpenVMS systems. This new architecture has a system management utility with a command line interface to manage the server components. See the Oracle SQL/Services Installation Guide for installation information and the Oracle SQL/Services Server Configuration Guide for information about configuring and managing the server. <> o New types of service that offer improved performance and enhanced database access security. Transaction reusable database services allow multiple client applications to share a few executor processes, thus reducing the number of processes on a system and so reducing the database contention between processes and reducing system resource usage. Session and transaction reusable database services may be configured with database access authorization set to the connect user name, forcing all database accesses to be executed using the client-supplied user name. o Support for SQL*Net as a transport type. See Section 1.3 for more information. You must specify the node_name parameter to the sqlsrv_ associate routine to be either the SQL*Net service name or the SQL*Net alias. o The server can be managed either on line or off line. See the Oracle SQL/Services Server Configuration Guide for more information. o SQLSRV_MANAGE changes. Oracle SQL/Services: New and Changed Features 1-5 The SQLSRV_MANAGE system management utility is changed in many ways to help make the utility more intuitive and easier to use. See the Oracle SQL/Services Server Configuration Guide for more information. <> o New sqlsrv_example.sqs file in SYS$COMMON:[SYSHLP.EXAMPLES.SQLSRV[70]]. The sqlsrv_example.sqs file contains a SQLSRV_MANAGE script that illustrates how to create two services: a universal service named, V61, and a transaction reusable database service named, PAYROLL, for a predetermined database. Note that all commands are commented out and you need to uncomment them to make them work. The script connects to the server, creates a universal service named, V61, that sets the SQL version to V6.1, specifies the owner of the V61 service as the sqlsrv$deflt account, sets database authorization to the connect username, grants the USE descriptor to all users (public), sets a minimum of 2 and a maximum of 20 executors, and starts the V61 service. The second portion of the script creates a transaction reusable database service named, PAYROLL, sets the SQL version to V7.0, attaches to the payroll_db database (not supplied with the kit), specifies the owner of the PAYROLL service as the payrollaccnt account, sets database authorization to the connect username, grants access to the payroll service to all users (public), sets a minimum and maximum of 5 executors and allows up to 20 clients per executor to run, and starts the PAYROLL service. <> o SQL initialization files are no longer executed during executor startup. In Oracle SQL/Services V6.1 on Digital UNIX, if a SQL initialization file was specified for a database service, the statements contained therein were executed during executor startup and whenever a new client connected to the service. Starting with Oracle SQL/Services V7.0, the statements contained in a SQL 1-6 Oracle SQL/Services: New and Changed Features initialization file are executed only when a new client connects to the service. <> o Updated sample source files are provided on the server system. Updated versions of the source files for the sample application are provided on the server system when you install an Oracle SQL/Services server kit. Use the following instructions to copy the files from an OpenVMS server system to a client system. 1. Copy the sample source files to a local directory: $ copy sys$common:[syshlp.examples.sqlsrv70]*.c *.* ! Multiversion, or $ copy sys$common:[syshlp.examples.sqlsrv]*.c *.* ! Standard install 2. Rename the source files, if necessary, for the target client system: For all Windows platforms: $ rename sqlsrv$driver.c sqsdrv.c $ rename sqlsrv$dynamic.c sqsdyn.c For all UNIX platforms: $ rename sqlsrv$driver.c sqsdrvu.c $ rename sqlsrv$dynamic.c sqsdynu.c For all Macintosh platforms: The file names are the same as they are on OpenVMS and therefore there is no need to rename them. 3. Copy the updated source files to your client system using an appropriate network file transfer utility. <> Use the following instructions to copy the files from a Digital UNIX server system to a client system. 1. Copy the sample source files to a local directory: % cp /usr/lib/dbs/sqlsrv/v70/examples/sqsd*.c . Oracle SQL/Services: New and Changed Features 1-7 2. Rename the source files, if necessary, for the target client system: For all Windows platforms: % mv sqsdrvu.c sqsdrv.c % mv sqsdynu.c sqsdyn.c For all OpenVMS and Macintosh platforms: % mv sqsdrvu.c 'sqlsrv$driver.c' % mv sqsdynu.c 'sqlsrv$dynamic.c' 3. Copy the updated source files to your client system using an appropriate network file transfer utility. <> o Oracle SQL/Services supports the specification of an rdb$client_defaults.dat file on OpenVMS systems. The Oracle SQL/Services DBSRC_FILE service attribute is not currently supported on OpenVMS. To specify values in either the rdb$client_defaults.dat file or the rdb$server_defaults.dat file, you must define a logical name that specifies the directory that contains one or both of the these files. To specify the directory on a per-process basis in the Oracle SQL/Services environment, you must create an executor process initialization command procedure that defines the RDB$USER_DEFAULTS logical name, then specify the file name of the procedure in the PROCESS_INITIALIZATION service attribute. Alternatively, you can define the RDB$SYSTEM_DEFAULTS logical as a system logical name or the RDB$GROUP_DEFAULTS logical name as a group logical name. See the Oracle Rdb7 SQL Reference Manual for more information. o Client access to accounts with expired passwords. By default, Oracle SQL/Services V6.1 and earlier allowed access to accounts with expired passwords. To disallow access to accounts with expired passwords, you defined the SQLSRV$CHECK_EXPIRED_PASSWORDS system logical name as T, t, Y, or y. 1-8 Oracle SQL/Services: New and Changed Features However, by default Oracle SQL/Services V7.0 does not allow access to accounts with expired passwords. To allow access to accounts with expired passwords, you must define the SQLSRV$CHECK_EXPIRED_PASSWORDS system logical name as F, f, N, or n. New and Changed Client Features The following describes new and changed client features: o Deprecated clients no longer ship with Oracle SQL/Services. All deprecated Oracle SQL/Services clients no longer ship on the Oracle SQL/Services software kit. o Macintosh for THINK C. The Macintosh for THINK C client API supports THINK C V8. Refer to the Guide to Using the Oracle SQL/Services Client API for changes in building applications and the sample application on the Macintosh operating system for THINK C. o Oracle ODBC Driver for Rdb V2.1. The Oracle ODBC Driver for Rdb for the MS Windows, Windows 95, Windows NT X86, and Windows NT Alpha operating systems is updated to V2.1 for Oracle SQL/Services V7.0. This release contains the following new features: - Support for Microsoft ODBC V2.01 specification. - Support for Microsoft ODBC Version 2.10 Driver Manager and Utilities DLLs for 16-bit applications. - Support for Microsoft ODBC Version 2.5 Driver Manager and Utilities DLLs for 32-bit applications. - Support for the Windows 95 platform. - Support for the SQL*Net transport on Microsoft Windows V3.1. - Support for Oracle Rdb Hold Cursors. - Support for the proxy access feature to avoid prompting for password information when using the SQLDriverConnect call. Oracle SQL/Services: New and Changed Features 1-9 - Notice of product name change from DEC Rdb Driver for MS Windows, Windows NT X86, and Windows NT Alpha operating systems to the Oracle ODBC Driver for Rdb for the MS Windows, Windows NT X86, and Windows NT Alpha operating system. With this change, some file names have also changed. See the Oracle ODBC Driver for Rdb release notes and help file for more information. o New Windows 95 client. An Oracle SQL/Services Windows 95 client is supported. o New Oracle SQL/Services Solaris client. An Oracle SQL/Services Solaris client is supported for V2.4 of Solaris. o New associate structure fields are available for general use. Three ASSOCIATE_STR fields that were marked "internal use" are now available for general use. The ASSOCIATE_STR now contains the following 3 fields: CHARPTR attach; /* Attach statement */ CHARPTR declare; /* Declare statement */ CHARPTR appnam; /* Client application name */ If the ASSOCIATE_STR VERSION field is set to SQLSRV_V610 or SQLSRV_V700, the Oracle SQL/Services client looks for these three fields in the ASSOCIATE_STR structure. The attach field can be used to specify an attach statement when associating to a universal service. By passing the attach statement in the ASSOCIATE_STR structure, rather than making a separate call to sqlsrv_ execute_immediate, you can save a round trip message to the server. The attach statement will be executed in the executor after the SQL init procedure (if any). The declare field can be used to specify a declare transaction statement; however, it can contain any SQL statement that can be executed using EXECUTE IMMEDIATE. As with the attach field, the declare field can be used to save a round trip message to the server. The declare statement is executed in the executor after the attach statement (if any). 1-10 Oracle SQL/Services: New and Changed Features The appnam field is for informational purposes only. The client application can pass the application name to the server using this field. The client application name is displayed when you issue a system management SHOW CLIENT command. o New value SQLSRV_INFO_BUFFER_SIZE for the info_type argument of the sqlsrv_get_associate_info routine. The info_type argument of the sqlsrv_get_associate_info routine has a new value SQLSRV_INFO_BUFFER_SIZE, that gets the negotiated client buffer size and returns this information as a longword. o The info_type parameter value, SQLSRV_INFO_DB_CLASS, of the sqlsrv_get_associate_info routine is deprecated in Oracle SQL/Services V7.0. This parameter value continues to work for Oracle SQL/Services V7.0; however, Oracle Corporation recommends that you use the new info_type parameter value, SQLSRV_INFO_SERVICE_ATTRS, which provides more information. See the Guide to Using the Oracle SQL/Services Client API for more information. o Client logging improvements. - New SQLSRV_LOG_FLUSH flag Client logging is frequently used to debug problems in client applications or in Oracle SQL/Services client/server components. In some situations, problems may exhibit themselves by the client application process terminating with an unhandled error condition such as a Windows general protection fault, Macintosh bus error, or other platform- specific condition. On many client platforms when a process terminates in this way, the operating system does not flush data written to output files, thus pending output to the Oracle SQL/Services client log may be lost. In Oracle SQL/Services V6.0, the SQLSRV_LOG_OPNCLS (64) option was added to force every line of output to be written the log file. Although this option solves the problem of lost output to the client log file, it can significantly slow down the execution of client applications when it is enabled. Oracle SQL/Services: New and Changed Features 1-11 To overcome the performance issue with the SQLSRV_ LOG_OPNCLS option, a new option, SQLSRV_LOG_FLUSH (128), is added to the logging flags bit mask. When the new SQLSRV_LOG_FLUSH option is enabled, the Oracle SQL/Services API flushes pending output to the client log file only at the end of each complete routine-level log entry and at the end of each protocol-level log entry. This greatly improves the performance of the client application when compared to the SQLSRV_LOG_OPNCLS option. Use the following guidelines when deciding which logging option to use: * If the client process is terminating due to an unhandled error condition in the client application, use the SQLSRV_LOG_FLUSH option to flush pending output to the client log before each call to an Oracle SQL/Services client API service completes. * If the client process is terminating due to an unhandled error condition in an Oracle SQL/Services client API service, then it may be necessary to use the SQLSRV_LOG_OPNCLS option to write as much information as possible to the log file during every call to an Oracle SQL/Services client API service. See the Guide to Using the Oracle SQL/Services Client API for more information. - New SQLSRV_LOG_BINARY flag The Oracle SQL/Services logging facility does not attempt to write data values that contain nonprintable binary characters to the client log file. However, in some situations, it is often useful to be able to verify that nonprintable data values are correct. A new logging option, SQLSRV_LOG_ BINARY (256), is available that logs all data values containing binary data in a formatted hexadecimal dump in the client log. For example: 1-12 Oracle SQL/Services: New and Changed Features ----SQLVAR INDEX SQLDATA SQLIND --------SQLSRV_SQLVAR_INDEX ------------len: 2, value: 0 --------SQLSRV_SQLVAR_SQLIND1 ------------len: 2, value: 0 --------SQLSRV_SQLVAR_SQLDATA1, len: 4073 ------------len: 1269, value: Non-printable data, formatted dump: ------------ 00270014 00070013 00000002 002E1C15 ..............'. 0000 ------------ 50206873 75726274 6E696150 FFFFFFFF ....Paintbrush P 0010 ------------ 05010068 73757242 50006572 75746369 icture.PBrush... 0020 ------------ 68737572 42500000 00070000 00020000 ..........PBrush 0030 ------------ 364D4200 04B46000 00000000 00000000 .........`...BM6 0040 ------------ 80000000 28000004 36000000 000004B4 .......6...(.... 0050 ------------ 00000000 00000800 01000001 E0000002 ...à............ 0060 ------------ 00000000 00000012 74000012 740004B0 °..t...t........ 0070 ------------ 00000080 00008000 00000000 00000000 ................ 0080 ------------ C0000080 80008000 80000000 80008080 ...............À 0090 ------------ FA00A6CA F000A4C8 F000C0DC C000C0C0 ÀÀ.ÀÜÀ..È...Ê..ú 00A0 ------------ E2001212 1200F2F2 F2000909 0900FAFA úú.....òòò.....â 00B0 See the Guide to Using the Oracle SQL/Services Client API for more information. - Date and time now logged To better aid the use of client logging as a debugging tool, the Oracle SQL/Services client API now logs the date and time at the start of each routine-level and protocol-level log entry. For example: ROUTINE LEVEL LOG at 16:16:09 on 20-May-1996 ----SQLSRV_FETCH --------CURSOR NAME ------------list_cursor PROTOCOL LEVEL LOG CLIENT: write (logonly) at 16:16:09 on 20-May-1996 ----PACKET ID: 9, PACKET SEQUENCE: 0 --------SQLSRV_FETCH ------------STATEMENT ID ----------------len: 4, value: 1000001 --------END OF MESSAGE - Client version identification in Oracle SQL/Services log file Oracle SQL/Services: New and Changed Features 1-13 The Oracle SQL/Services client version identifier is written at the beginning of each client log file on all client platforms. On all MS Windows platforms, the Oracle SQL/Services API DLL file location is also written. - Additional client logging changes In the protocol-level log messages, and specifically in the associate message, the word "CLASS" is replaced with the word "SERVICE NAME". In the SQLSRV_ ASSOCIATE ACK message, CLIENT PROTOCOL VERSION and ASSOCIATE ID are no longer returned; EXC SRV PID is changed to EXECUTOR PID and DB CLASS INDICATOR is changed to SERVICE ATTRIBUTES. In the protocol-level log, Oracle SQL/Services V7.0 uses a new optimized protocol to exchange SQLDA data between clients and servers where the SQLVAR index, the SQLDATA and SQLIND values are sent using a single tag. The data type of the SQLDATA value is no longer sent at this time, only an indicator whether an SQLDA or SQLDA2 is being used. See the Guide to Using the Oracle SQL/Services Client API for more information. o Clients can now use standard SQLDA-style SQLDAs to access SQLDA2 data types. In versions of Oracle SQL/Services prior to V7.0, the only supported mechanism to access SQLDA2 data types, such as the DATE ANSI, TIME, TIMESTAMP, and INTERVAL data types, was for the client application to also use SQLDA2-style SQLDAs. Beginning with Oracle SQL/Services V7.0, clients can use standard SQLDA-style SQLDAs to access SQLDA2s data types. The Guide to Using the Oracle SQL/Services Client API describes how to access SQLDA2 using SQLDA-style SQLDAs. Although some metadata information for these data types, such as the SQLCHRONO_PRECISION, is not available; if this information is not required, then a client application can reduce memory usage at the client and server and reduce the length of network messages by using SQLDA instead of SQLDA2. o Date and time sub-types now defined in sqlsrv.h. 1-14 Oracle SQL/Services: New and Changed Features The SQLSRV_GENERALIZED_DATE date and time and SQLSRV_ INTERVAL sub-types are now defined in sqlsrv.h. For example: #define SQLSRV_DT_DATE_VMS 0 #define SQLSRV_DT_DATE_ANSI 1 #define SQLSRV_DT_TIME 2 . . . #define SQLSRV_DT_YEAR 1 #define SQLSRV_DT_MONTH 2 #define SQLSRV_DT_DAY 3 #define SQLSRV_DT_HOUR 4 . . . o Preparing statements in transaction reusable executors no longer changes the transaction state. In versions of SQL prior to V7.0, when a client application requested that an executor prepare a new statement, SQL would sometimes implicitly start a new transaction to read the metadata from the database. This could pose a problem for a transaction reusable service if the client application did not immediately either issue one or more subsequent requests or commit the transaction, ignoring SQL_NO_TXN (-1005) and SQL_ NOIMPTXN (-1008) errors. Beginning with SQL V7.0 and Oracle SQL/Services V7.0, when using a transaction reusable service, Oracle SQL/Services now directs SQL to not change the transaction state when preparing a new statement. If a client application wishes to prepare a number of transactions, perhaps executing some intervening data access requests, then the application can start an explicit transaction before preparing or executing the necessary statements (or both). <> o SQLSRV_FTCMNYACT error added to sqlsrv.h as -2057. Oracle SQL/Services: New and Changed Features 1-15 In versions of Oracle SQL/Services previous to V7.0, the error SQLSRV_FTCMNYACT was not defined in sqlsrv.h. However, the Guide to Using the Oracle SQL/Services Client API documentation states that the sqlsrv_fetch_ many() API routine returns SQLSRV_FTCMNYACT if fetch- many mode is already active for the specified cursor. Furthermore, sqlsrv_fetch_many() would incorrectly return a value of 1 in this situation. For Oracle SQL/Services V7.0, the SQLSRV_FTCMNYACT error is now defined in sqlsrv.h as -2057 and the sqlsrv_fetch_ many() API routine now correctly returns the new value if this error condition is detected. o Oracle SQL/Services supports larger client buffer sizes for the DECnet and TCP/IP transports. Oracle SQL/Services supports client buffer sizes up to 32000 bytes for the DECnet and TCP/IP transports for clients attaching to a V7.0 Oracle SQL/Services server. If a client connects to a pre-V7.0 server, and the client specifies a larger buffer size than the server can handle, the client will release the association and try again with a smaller buffer size. If a client connects to a V7.0 or later server, and the client specifies a larger buffer size than the server can handle, the client adjusts the buffer size without having to reconnect. See the description of the sqlsrv_associate routine in the Guide to Using the Oracle SQL/Services Client API for more information. Performance Features Oracle SQL/Services V7.0 contains the following performance optimizations: o Improved protocol for exchanging SQLDATA values between client and server. Oracle SQL/Services now uses a single tag to describe the SQLVAR index, SQLIND values, and SQLDATA values when sending SQLDA data values between client and server, and server and client. The new protocol not only reduces the size of network messages, but also requires less CPU time to build and parse messages. o Stale data values are no longer sent if the NULL indicator is set. 1-16 Oracle SQL/Services: New and Changed Features In versions of Oracle SQL/Services prior to V7.0, the message build code did not take into account the SQLIND NULL indicator when building messages to exchange data between the client and server. This resulted in stale data being sent over the network when the SQLIND value indicated a NULL value. Beginning with Oracle SQL/Services V7.0, no data is sent for a column when the SQLIND NULL indicator is set to -1. o Select-list SQLLEN values are not sent in a FETCH message if the values are unchanged. Client applications can adjust the length of SQLSRV_ CHAR, SQLSRV_VARCHAR, and SQLSRV_VARBYTE column values returned by the server by calling the sqlsrv_sqlda[2]_ set_sqllen SQL/Services client API service. In versions of Oracle SQL/Services prior to V7.0, the Oracle SQL/Services client API always sent all the select list SQLLEN values to the server, even if none of the values had been changed by the client application. Beginning with Oracle SQL/Services V7.0, the client sends a select list SQLLEN value to the server only if the value has been changed by the client application. This greatly reduces the size of FETCH messages for most client applications. o Statement ID is now sent in the FETCH message. In versions of Oracle SQL/Services prior to V7.0, the Oracle SQL/Services client API sent the cursor name to the server in the FETCH message when the client application called sqlsrv_fetch to retrieve the next row from a result table. Beginning with Oracle SQL/Services V7.0, the client application sends the binary statement ID to the server. Looking up a statement using the binary statement ID is much faster than looking up a statement using the cursor name. To further improve fetch performance, the server now maintains a pointer to the most recently used statement. When combined with the select-list SQLLEN optimization described previously, this optimization significantly reduces the length of most FETCH messages. o Improved memory usage in the executor for SQLDA clients accessing SQLDA2 data types. Oracle SQL/Services: New and Changed Features 1-17 For SQLDA clients, such as the Oracle ODBC Driver for Rdb, that use SQLDA-style SQLDAs to access SQLDA2 data types, such as the DATE ANSI, TIME, TIMESTAMP, and INTERVAL data types, the executor now describes the metadata using an SQLDA2-style SQLDA, but executes the statements using an SQLDA-style SQLDA. This greatly reduces the amount of memory consumed by the executor; an SQLDA2 SQLVAR is over 10 times the size of an SQLDA SQLVAR. o Improved executor startup time. The Oracle SQL/Services V7.0 executor now uses a private mode of rdb$setver.com that improves executor startup performance by defining only the logical names and looking up only the component version numbers actually required by Oracle SQL/Services. New and Changed Server Management Features The following describes new and changed server management features: o New Oracle SQL/Services Manager graphical user interface (GUI) to manage an Oracle SQL/Services server from a PC Windows client. You can use an Oracle SQL/Services Manager GUI to manage Oracle SQL/Services server systems from any one of the following PC Windows clients: MS Windows V3.1, Windows 95, Windows NT X86, or Windows NT Alpha. From a PC Windows client running the Oracle SQL/Services Manager client software, an Oracle SQL/Services system administrator can connect to any server on any node for which a transport (DECnet or TCP/IP) is available. Once connected, the Oracle SQL/Services system administrator can alter server, dispatcher, and service attributes; create and drop dispatchers and services; start and shut down dispatchers and services; restart servers, dispatchers, and services; grant and revoke authorization to users (clients) to use a service, and show all clients (users) who are using a service. The only tasks Oracle SQL/Services system administrator cannot do from an Oracle SQL/Services Manager Client is to create, start, shut down, and drop a server; these tasks must be done on the server side of 1-18 Oracle SQL/Services: New and Changed Features the client/server system, using either the SQLSRV_MANAGE utility or an SQLSRV_MANAGE script. o A privileged local user can connect to the server without supplying a user name and password from OpenVMS and Digital UNIX SQLSRV_MANAGE clients. A privileged local user using either an OpenVMS or Digital UNIX SQLSRV_MANAGE client can connect to the server without having to pass a user name and password. The OpenVMS account needs the SYSPRV or BYPASS privilege and the Digital UNIX account needs to be 'root' to omit using a user name and password. No privileges are needed if you are connecting using DECnet on OpenVMS. This mechanism only works for TCP/IP on Digital UNIX. New and Changed General Features The following describes new and changed general features: o Terminology changes for the Oracle SQL/Services V7.0 server. In the Oracle SQL/Services documentation that describes the server for OpenVMS systems, some of the Oracle SQL/Services terminology is changed. The following terminology changes reflect changes made to the server architecture on OpenVMS systems for V7.0: - The term dispatcher replaces all instances of the phrase communications server. - The term executor or executors replaces all instances of the phrase execute server process or execute server processes. - The term service replaces all instances of the term class. - The term universal replaces all instances of the term generic, except for the service named "GENERIC". <> o Help files are updated for V7.0 for the following server platforms: - OpenVMS Alpha - OpenVMS VAX - Digital UNIX Oracle SQL/Services: New and Changed Features 1-19 o Help files are updated for the following client platforms: - OpenVMS Alpha and OpenVMS VAX - MS Windows V3.1, Windows 95, Windows NT X86, and Windows NT Alpha, - Oracle ODBC Driver for Rdb for the MS Windows operating system, - Oracle ODBC Driver for Rdb for the Windows 95 operating system, - Oracle ODBC Driver for Rdb for the Windows NT X86 operating system - Oracle ODBC Driver for Rdb for the Windows NT Alpha operating system o Using alternate server network ports with Oracle SQL/Services clients The server allows the system manager to define nondefault server network ports in the Oracle SQL/Services server to allow for multiple versions of Oracle SQL/Services to run on the same system. See the Oracle SQL/Services Installation Guide for more information. 1.3 Using SQL*Net as a Network Transport in Oracle SQL/Services V7.0 Oracle SQL/Services supports SQL*Net as a new network transport type on OpenVMS, Digital UNIX, and MS Windows. With Oracle SQL/Services V7.0, you can use SQL*Net as the network transport between Oracle SQL/Services clients and dispatchers. The following sections describe parameters in Oracle7 SQL*Net configuration files, which are used by Oracle SQL/Services. The Oracle Network Manager creates Oracle7 SQL*Net configuration files. 1-20 Oracle SQL/Services: New and Changed Features 1.3.1 New Concepts or New Terminology With SQL*Net, clients access servers using SQL*Net service names or SQL*Net aliases. A service name translates to a connection string that consists of the following parts: o ADDRESS-transport protocol, node name, and transport- specific parameters such as port number or object name o CONNECT_DATA-Oracle SQL/Services V7.0 service name For example, an SQL*Net service name and its translated string may appear as follows: db1.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = com1.world) (PROTOCOL = TCP) (Host = figmnt) (Port = 1526) ) ) (CONNECT_DATA = (SERVICE = generic) (GLOBAL_NAME = generic.world) ) (SDU= 2048) ) In the previous example, "db1" is the SQL*Net service name and ".world" is the community in a Hierarchical Naming Space. An ADDRESS_LIST can consist of multiple addresses. Each ADDRESS has full connection parameters of a server. CONNECT_DATA consists of a SERVICE parameter where an Oracle SQL/Services Version 7.0 service name should be specified. In this case, the universal service named "GENERIC" is specified. Optionally, you can specify a client buffer size with the SDU parameter. ________________________ Note ________________________ Oracle Network Manager begins support of the SERVICE parameter in release 3.1.0.1.0. In prior releases of Oracle Network Manager, use the SID parameter in place of the SERVICE parameter. ______________________________________________________ Oracle SQL/Services: New and Changed Features 1-21 SQL*Net service names and aliases are created by the Oracle Network Manager utility. On the server side, the Oracle SQL/Services V7.0 dispatchers read listening addresses from SQL*Net listener address lists, defined under SQL*Net listener names. For example, an SQL*Net listener name and its translated address list may look as follows: LISTENER = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = com1.world) (PROTOCOL = TCP) (Host = figmnt) (Port = 1526) ) ) SQL*Net listener names are created by the Oracle Network Manager utility. 1.3.2 Oracle SQL/Services Client API Use the SQLSRV_ASSOCIATE service to initiate a connection using SQL*Net. Specify an SQL*Net service name or SQL*Net alias to the node_name argument. If you use the association structure to specify the transport type, set the value as follows: o ASSOCIATE_STR.xpttyp = SQLSRV_XPT_SQLNET An example of specifying an SQL*Net service name would be as follows: sqlsrv_associate ( , ... ); For the SQL*Net transport, the ASSOCIATE_STR.class field should be set to NULL. Any value in that field will be ignored. As a reminder, the Oracle SQL/Services service name is specified in the SQL*Net connection string through the Oracle Network Manager. 1-22 Oracle SQL/Services: New and Changed Features 1.3.3 Oracle SQL/Services Server Configuration When creating a dispatcher for a server, define the name of the SQL*Net listener name using the CREATE DISPATCHER command using the following syntax: CREATE DISPATCHER where = NETWORK-PORT = | | = SQLNET LISTENER_NAME is an Note that the LISTENER_NAME can be abbreviated to LISTENER and that denotes the SQL*Net listener name, which must match the name in an SQL*Net listener address list mentioned in the previous section. For example, SQLSRV manage> CREATE DISPATCHER NETWORK_PORT SQLNET LISTENER_NAME "LISTENER"; The can be repeated to include multiple SQL*Net listener names (up to 5.) 1.3.4 Oracle Network Manager The Oracle Network Manager is a tool that configures and administers all Oracle network products. It generates SQL*Net configuration files that contain definitions of SQL*Net service names, SQL*Net aliases, and SQL*Net listener names. In Oracle Network Manager, objects that are relevant to Oracle SQL/Services are as follows: o Community-defines a domain and protocol of a community o Node-defines the system type (that is, OpenVMS, Digital UNIX, and so forth) and adjoins a domain and a community o Listener-defines the node where a listener resides, defines protocol-specific listening parameters, defines the list of Oracle SQL/Services services to be serviced by an Oracle SQL/Services dispatcher, and defines the location of SQL*Net tracing and logging files for an Oracle SQL/Services dispatcher o Database-defines the Oracle SQL/Services database service and universal service name Oracle SQL/Services: New and Changed Features 1-23 o Client Profile-adjoins a domain and a community and defines the location of SQL*Net tracing and logging files for clients o Alias-defines an alias for an Oracle SQL/Services service Oracle SQL/Services V7.0 uses the following configuration files generated by the Oracle Network Manager: o listener.ora-contains the SQL*Net listener names and their translated address lists for listening, the location of tracing and logging files for Oracle SQL/Services V7.0 dispatchers, and is used by Oracle SQL/Services V7.0 dispatchers at startup time o sqlnet.ora-contains SQL*Net general parameters, the location of tracing and logging files for Oracle SQL/Services V7.0 clients, and is used by Oracle SQL/Services V7.0 dispatchers and clients o tnsnames.ora-contains SQL*Net service names and aliases, and is used by Oracle SQL/Services V7.0 dispatchers and clients o tnsnav.ora-defines communities and is used by the Oracle SQL/Services V7.0 dispatchers and clients 1.3.5 Creating Oracle Network Manager Configuration Files Oracle SQL/Services V7.0 supports SQL*Net network configuration files generated by Oracle Network Manager V3.0 or higher. ________________________ Note ________________________ Oracle Network Manager V3.0 is available through the Oracle System Management Products V1.0 and it runs on MS Windows only. ______________________________________________________ To use the Oracle Network Manager to create SQL*Net configuration files for Oracle SQL/Services V7.0, follow these steps: 1. Select the "Oracle Network Manager" icon. 2. Select "File" as storage location. 1-24 Oracle SQL/Services: New and Changed Features 3. Open a file. If you are creating a new file, Oracle Network Manager creates a file with ".net" as the file type and a subdirectory with the same name as the file. Within this subdirectory, the Oracle Network Manager creates several subdirectories, one for each server node and one for clients of each community. Each of these subdirectories consists of configuration files for the node or the community. 4. Select "Create" to create the following objects: Community Node Listener Database Client Profile Alias This step is self-explanatory as you browse through each object window. 5. Select "Validate" under "File" to validate all the objects that you have created. 6. Select "Generate" under "File" to generate configuration files. For each server node, the Oracle Network Manager generates four files in the subdirectory of the server node: listener.ora sqlnet.ora tnsnames.ora tnsnav.ora For each community, the Oracle Network Manager generates three files in the subdirectory of the community: sqlnet.ora tnsnames.ora tnsnav.ora Oracle SQL/Services: New and Changed Features 1-25 1.3.6 Distributing Oracle Network Manager Configuration Files SQL*Net looks for configuration files at the TNS_ADMIN location. On OpenVMS systems, the logical name TNS_ADMIN is used. On MS Windows and Digital UNIX systems, the environmental variable TNS_ADMIN is used. For the Oracle SQL/Services V7.0 server node, copy all four configuration files of the server node to the TNS_ADMIN location before starting any Oracle SQL/Services dispatcher that uses SQL*Net. For the Oracle SQL/Services V7.0 client node, copy all three configuration files of the community to the TNS_ADMIN location before running any client that uses SQL*Net. There is an example configuration file in the form of an OpenVMS saveset file, SQLNET_SAMPLE70.BCK, in the SYS$COMMON:[SYSHLP.EXAMPLES.SQLSRV[70]] directory. 1.3.7 SQL*Net Network Tracing and Logging Files You can enable SQL*Net network tracing and logging through the Oracle Network Manager. When a listener object is created, specify the network tracing level and the location of the network tracing and logging files for the Oracle SQL/Services dispatcher. After a community object is created, modify the client profile object for that community for network tracing and logging information. This determines the SQL*Net network tracing and logging parameters for Oracle SQL/Services clients of the community. 1.4 Deprecated Features The following Oracle SQL/Services features are deprecated. These features are no longer described in the main body of the Guide to Using the Oracle SQL/Services Client API and Oracle SQL/Services Installation Guide and are described in detail only in an appendix in the Guide to Using the Oracle SQL/Services Client API. Oracle will not enhance features that are deprecated. Oracle may announce in a future version of Oracle SQL/Services that these deprecated features are obsolete and can no longer be used. Therefore, applications that use these features should be modified accordingly, when possible. 1-26 Oracle SQL/Services: New and Changed Features o MS-DOS large memory model client API The MS-DOS large memory model client API is deprecated in Oracle SQL/Services V7.0, is frozen at the V6.1 level, and will not be enhanced in future releases. The MS-DOS large memory model client API was supplied with the V6.1 kit. It is not supplied with the V7.0 kit. o MS-DOS medium memory model client API The MS-DOS medium memory model client API was deprecated in Oracle SQL/Services V5.1, is frozen at the V4.2 level, and will not be enhanced in future releases. The MS-DOS medium memory model client API was supplied with the V5.1 kit. It is not supplied with the V7.0 kit. o ULTRIX for VAX client API The ULTRIX for VAX client API was deprecated in Oracle SQL/Services V5.1, is frozen at the V4.2 level, and will not be enhanced in future releases. The ULTRIX for VAX client API was supplied with the V5.1 kit. It is not supplied with the V7.0 kit. o ULTRIX for RISC client API The ULTRIX for RISC client API is deprecated in Oracle SQL/Services V7.0, is frozen at the V6.1 level, and will not be enhanced in future releases. The ULTRIX for RISC client API was supplied with the V6.1 kit. It is not supplied with the V7.0 kit. o SunOS client API The SunOS client API is deprecated in Oracle SQL/Services V7.0, is frozen at the V6.1 level, and will not be enhanced in future releases. The SunOS client API was supplied with the V6.1 kit. It is not supplied with the V7.0 kit. o OS/2 client API The OS/2 client API was deprecated in Oracle SQL/Services V5.1, is frozen at the V4.2 level, and will not be enhanced in future releases. The V4.2 OS/2 client API was supplied with the V5.1 kit. It is not supplied with the V7.0 kit. o VAX format of all API routines Oracle SQL/Services: New and Changed Features 1-27 The VAX format for all API routines was deprecated in Oracle SQL/Services V5.0. o Association routines - info_type parameter value, SQLSRV_INFO_DB_CLASS, of the sqlsrv_get_associate_info routine The info_type parameter value, SQLSRV_INFO_DB_ CLASS, of the sqlsrv_get_associate_info routine is deprecated in V7.0. However, this parameter value will continue to work for Oracle SQL/Services V7.0. The SQLSRV_INFO_DB_CLASS parameter value describes a flag that returns true if the client is connected to a database service; the value is returned as a longword. This is useful to determine whether an attach is required after the association. Oracle Corporation recommends that you use the new info_type parameter value SQLSRV_INFO_SERVICE_ATTRS, which returns more information about the service. - sqlsrv_set_server_class The sqlsrv_set_server_class routine was deprecated in Oracle SQL/Services V6.1. Oracle Corporation recommends that you use the class_name field in the association structure as the method of choosing a server class because this method works for multiassociation applications. - sqlsrv_set_transport_type The sqlsrv_set_transport_type routine was deprecated in Oracle SQL/Services V6.1. Oracle Corporation recommends that you use the xpttyp field in the association structure to choose a transport because this method works for multiassociation applications. o SQL statement routine - sqlsrv_execute-Execute prepared statement The routine sqlsrv_execute was deprecated in Oracle SQL/Services V7.0. Oracle Corporation recommends that you code your applications using the sqlsrv_execute_ in_out routine. o Functional interface routines - sqlsrv_sqlda_map_data-Return column information 1-28 Oracle SQL/Services: New and Changed Features The routine sqlsrv_sqlda_map_data was deprecated in Oracle SQL/Services V5.0. Oracle Corporation recommends that you code your applications using the sqlsrv_sqlda_ref_data routine. - sqlsrv_sqlda_unmap_data-Free resources The routine sqlsrv_sqlda_unmap_data was deprecated in Oracle SQL/Services V5.0. Oracle Corporation recommends that you code your applications using the sqlsrv_sqlda_unref_data or sqlsrv_sqlda2_unref_ data routine. - sqlsrv_sqlca_num_batch_rows-Return number of rows processed in a batch operation Previous versions of the Guide to Using the Oracle SQL/Services Client API described a routine named sqlsrv_sqlca_num_batch_rows as returning the number of rows processed in a batched execution operation from the SQLERRD[1] field of the SQLCA. The Oracle SQL/Services server does not maintain or return a count of the rows processed; therefore, this routine always returned 0. This routine is therefore deprecated in Oracle SQL/Services V7.0. Oracle Corporation recommends that you use the sqlsrv_sqlca_ count client API routine to retrieve the number of rows processed in a batched execution operation. 1.5 Obsolete Features An obsolete feature is one that is no longer supported and that was described as a deprecated feature in a previous release. These features no longer work. o Association routines - sqlsrv_get_environment-Return environment variable values The sqlsrv_get_environment routine was obsolete beginning with V6.1. This routine no longer exists. - sqlsrv_set_environment-Set environment variable values The sqlsrv_set_environment routine was obsolete beginning with V6.1. This routine no longer exists. Oracle SQL/Services: New and Changed Features 1-29 o sqlsrv_set_filter-Define filter for result table The sqlsrv_set_filter was obsolete beginning with Oracle SQL/Services V4.2. This routine no longer exists. o Structures - SQLSRV_ENV_STR-Environment variable structure The SQLSRV_ENV_STR structure was obsolete beginning with V6.1. This structure no longer exists. o Local Mode Local mode was obsolete beginning with Oracle SQL/Services V6.1. The local mode flag is ignored beginning with V6.1 if it is set in the association structure. 1-30 Oracle SQL/Services: New and Changed Features 2 _________________________________________________________________ Software Errors Fixed This chapter describes problems with previous versions of the Oracle SQL/Services software that are fixed in V7.0. 2.1 Oracle SQL/Services Server Errors Fixed for V7.0 This section contains errors fixed for the Oracle SQL/Services server for V7.0. 2.1.1 Problems Fixed in the Oracle SQL/Services V7.0 Server The following known problems found in Oracle SQL/Services OpenVMS and Digital UNIX V6.1 servers and previous releases are fixed in V7.0: o Installations of Oracle SQL/Services previous to V7.0 did not check to see if the Oracle SQL/Services accounts already existed. This problem is fixed in V7.0. Now during installation, Oracle SQL/Services checks to see if the accounts it normally creates already exist. If they do, Oracle SQL/Services does the following: - It makes sure quotas are at least the minimum required by Oracle SQL/Services (but Oracle SQL/Services no longer lowers quotas that are higher than the minimums). - It ensures that the default device exists. If it does not exist, it prompts the user for a new one. - It ensures that the default directory exists and is owned by the account. If not, Oracle SQL/Services either creates the directory or sets its owner to the account, or does both. <> Software Errors Fixed 2-1 o The installation procedure did not ask if you wanted to shut down a running server prior to installing a more recent version of Oracle SQL/Services. In versions of Oracle SQL/Services previous to V7.0, the installation procedure did not ask if you wanted to shut down a running server prior to installing a more recent version. This problem is fixed in V7.0. The installation procedure now asks if you want to shut down a running server prior to the installation of V7.0. <> o Oracle SQL/Services did not check for NOIMPTXN (No Implicit Transaction Outstanding) Errors on the Rollback Operation. In Oracle SQL/Services V6.0A and V6.1, Oracle SQL/Services executors began checking for errors during cleanup between clients. The intent was to run down executors if Oracle SQL/Services could not properly cleanup from a client, so the next client would have a consistent executor process in which to run. When a client makes an sqlsrv_release call from a universal service, Oracle SQL/Services does the following cleanup: 1. Commits the transaction. 2. Rolls back the transaction, if there is an error. 3. Disconnects from the database. When a client makes an sqlsrv_release call from a database service, Oracle SQL/Services performs the transaction commit or rollback operation, but it does not disconnect from the database. In V6.0A and V6.1, Oracle SQL/Services stopped the executor process if it got an unexpected error on a rollback or a disconnect operation. Oracle SQL/Services was checking for SQL NO_TXNOUT (no transaction outstanding) errors on the rollback operation, but it did not check for SQL NOIMPTXN (no implicit transaction outstanding) errors on the rollback operation. This 2-2 Software Errors Fixed caused Oracle SQL/Services to run down executor processes when it was not needed. This problem is fixed in V7.0. Oracle SQL/Services no longer runs down executor processes when it gets a no implicit transaction error on the rollback operation. <> o In V6.1, Oracle SQL/Services corrupted the stack due to incorrect handling of SQLDA2 data types (such as ANSI DATE, TIME, TIMESTAMP and INTERVAL) from clients coded to use SQLDA (such as the Oracle ODBC Driver for Rdb). This problem is fixed in V7.0. o Executors signaled INVLOCKID and produced a bugcheck or process dump when the V6.1 communications server was shut down. In Oracle SQL/Services V6.1, when a communications server was shut down, executors signaled the INVLOCKID error and produced a bugcheck or process dump. This problem is fixed in V7.0. With the new Oracle SQL/Services server implementation in V7.0, this problem does not exist. <> o Restriction with multisession applications and transaction reusable database services is lifted. Some applications, such as Microsoft Access, use multiple associations to the Oracle SQL/Services server environment to access data in a database. If an application has the ability to start concurrent transactions on multiple associations, then it is possible for the application to deadlock itself if two or more associations are allocated to the executor process. This is because a transaction reusable executor is unable to start a subsequent transaction until the initial transaction completes; however, the initial transaction will never complete because the application will be stalled waiting for the subsequent transaction to start. Software Errors Fixed 2-3 This problem is fixed in the Oracle SQL/Services server for V7.0. A new argument, APPLICATION_TRANSACTION_USAGE {SERIAL | CONCURRENT}, for the CREATE SERVICE and ALTER SERVICE commands prevent multiple associations from the same client application on a single client node being assigned to the same executor process and thus entering into a potential deadlock state when the keyword CONCURRENT is specified. See the Oracle SQL/Services Server Configuration Guide for more information. <> o SQL tinyint data type with a scale factor was not handled correctly. Oracle SQL/Services returns the scale factor of all columns with integer data types in the high-order byte of the column's SQLLEN field following the successful completion of a call to the sqlsrv_prepare routine. However, in Oracle SQL/Services Version 6.1 and earlier, the scale factor returned for a column with the tinyint data type was always 0, even if the column in the database had a nonzero scale factor. This problem is fixed in V7.0. Note that the scale factor returned to a client using SQLDA2 was always correct. o Problem with stored procedures with ANSI DATE, TIME, TIMESTAMP, or INTERVAL data type arguments. In Oracle SQL/Services Version 6.1 and earlier, the executor would sometimes bugcheck if a client prepared a call to a stored procedure that had at least one output or input/output argument with a data type of DATE ANSI, TIME, TIMESTAMP, or INTERVAL. This problem is fixed in V7.0. Note that this problem did not occur if the client used SQLDA2. o Executor returned an %SQL-F-CURALRDCL error if the open cursor failed. In versions of Oracle SQL/Services prior to V7.0, the executor returned the "%SQL-F-CURALRDCL, Statement already declared as cursor TABLE_CURSOR" error message to the client on the second and subsequent calls to sqlsrv_open_cursor for a statement ID if the first call to sqlsrv_open_cursor for the same statement ID completed with an error because the SQL OPEN statement 2-4 Software Errors Fixed failed. For example, the SQL OPEN statement might fail because an invalid number was specified for a parameter marker of type SQLSRV_GENERALIZED_NUMBER. This error occurred because the executor incorrectly tried to redeclare the cursor for the second and subsequent calls to sqlsrv_open_cursor. This problem is fixed in V7.0. The executor no longer attempts to redeclare the cursor on the second and subsequent calls to sqlsrv_open_cursor if the first call to sqlsrv_open_cursor fails. o Executor did not remove trailing semicolons (;) from ATTACH and DECLARE TRANSACTION statements. In versions of Oracle SQL/Services prior to V7.0, an executor for a database service would not start if the ATTACH statement specified using the Oracle SQL/Services Manager GUI contained a trailing semi-colon (;) character. This problem is fixed in V7.0. The executor now removes trailing semi-colon (;) characters from database service ATTACH strings, and from ATTACH and DECLARE TRANSACTION strings specified by a client application in the ASSOCIATE_STR structure. o Executor produced a bugcheck if the connection to the database service failed. In versions of Oracle SQL/Services prior to V7.0, an executor would produce a bugcheck if a new client connection to a database service with database authorization set to connect user failed for any reason other than SQL_NO_PRIV (-1028; %RDB-E-NO_PRIV, privilege denied by database facility). This problem is fixed in V7.0. If a new client connection to a database service fails for any reason, the error is written to the executor's log file and returned to the client application. <> o Executor aborted if the client called sqlsrv_execute with the execute flag set to SQLSRV_EXE_ABORT. Software Errors Fixed 2-5 In versions of Oracle SQL/Services previous to V7.0, the executor process would abort if a client called sqlsrv_ execute with the execute flag set to SQSLRV_EXE_ABORT and if the previous call to sqlsrv_execute was made with the execute flag set to anything other than SQLSRV_EXE_ BATCH. This problem is fixed in V7.0. o Executor did not free memory if the client terminated in batch-execute mode. In versions of Oracle SQL/Services previous to V7.0, the executor process did not release the memory allocated to queued requests if a client application terminated having previously queued but not executed a number of requests using the SQLSRV_EXE_BATCH execute flag. This problem is fixed in V7.0. o Executor aborted if the client called sqlsrv_close_ cursor to end a fetch-many request. In versions of Oracle SQL/Services prior to V7.0, it was possible for an executor to abort with a "SQLSRV- F-INVSTT, Invalid comm server state" status if a client called sqlsrv_close_cursor to end a fetch-many request and the executor had retrieved the last row requested by the client but had not yet completed sending the last packet of the response back to the client. This problem is fixed in V7.0. o Executor aborted if the SQLDA client prepared a CALL statement with SQLDA2 arguments. In versions of Oracle SQL/Services prior to V6.1 ECO02, the executor aborted if an SQLDA client, such as the Oracle Rdb ODBC driver, prepared a call to a stored procedure with an SQLDA2 output argument, such as a DATE ANSI, TIME, TIMESTAMP, or INTERVAL data type. In Oracle SQL/Services version V6.1 ECO02, the executor would abort if a SQLDA client, such as the Oracle Rdb ODBC driver, prepared a call to a stored procedure with an SQLDA2 input argument, such as an ANSI DATE, TIME, TIMESTAMP, or INTERVAL data type, but no output arguments. Both of these problems are fixed in V7.0. 2-6 Software Errors Fixed o Executor incorrectly handled over-long data values from clients. In versions of Oracle SQL/Services prior to V7.0, an executor process' memory was corrupted if a client sent an over-long data value to the server in a parameter marker SQLDA. A data value was considered over-long if its length exceeded the SQLLEN value for the column. This problem is fixed in V7.0. The following list describes how the Oracle SQL/Services executor handles an over-long data value of each supported data type. In all cases, the Oracle SQL/Services executor re- allocates the SQLDATA memory it has already allocated to the parameter marker value before processing the data value from the client. - SQLSRV_ASCII_STRING, SQLSRV_VARCHAR After reallocating the parameter marker SQLDATA memory for the column, the executor passes the data directly to SQL. Typically, SQL simply truncates an over-long string value to the metadata size defined for the column in the database. - SQLSRV_VARBYTE After reallocating the parameter marker SQLDATA memory for the column, the executor passes the data directly to SQL. Oracle Rdb allows a segment of any size to be inserted into a segmented string, regardless of the segment size specified when the column was defined. - SQLSRV_GENERALIZED_NUMBER, SQLSRV_GENERALIZED_DATE, SQLSRV_INTERVAL The Oracle SQL/Services executor allocates additional memory for each parameter marker column for these data types over and above the SQLLEN size that is determined when a statement is prepared. If the length of a data value exceeds the actual memory allocated, then the executor returns a SQLSRV_DATA_ TOO_LONG (-2058) error to the client application. The error message text contains the full data value and the column name. For example: Software Errors Fixed 2-7 %SQLSRV-E-DATA_TOO_LONG, SQLDATA value 000000000000000000000000005 too long for column name F_ROW_ID index 0 (max. length 16) - SQLSRV_LIST_VARBYTE The Oracle SQL/Services SQLSRV_LIST_VARBYTE (SQL_ SEGSTRING) data type is used to hold the database address (DBKEY) of a segmented string. Although Oracle SQL/Services reallocates the SQLDATA memory and passes the entire value to SQL, the results are unpredictable. A client application should never alter the length of a SQLSRV_LIST_VARBYTE data value. See the Data Types chapter in the Guide to Using the Oracle SQL/Services Client API for more information. o Executor aborted if the client called sqlsrv_fetch with an invalid cursor name. In versions of Oracle SQL/Services prior to V7.0, the executor produced a bugcheck if a client called sqlsrv_fetch with the name of a cursor that had not been successfully opened. This problem is fixed in V7.0. o The sqlsrv_associate service call failed with %RDB-F- AUTH_FAIL error if the identifier did not exist. In versions of Oracle Rdb previous to V7.0, if a client application attempted to connect to a database service with database authorization set to connect user, then the sqlsrv_associate call failed with a SQL_RDBERR (-1), "%RDB-F-AUTH_FAIL, authentication failed for user !AC" error if there was no identifier for the user account's user identification code (UIC) or if the name of the UIC identifier did not match the user name. This problem is fixed in Oracle Rdb V7.0. User accounts no longer need a UIC or a UIC that matches the user name. <> o The sqlsrv_associate service call incorrectly partially succeeded if the user was not authorized to access a database. 2-8 Software Errors Fixed In versions of Oracle Rdb previous to V7.0, if a client application attempted to connect to a database service with database authorization set to connect user, then the sqlsrv_associate call would sometimes succeed even if the user was not authorized to access the database. Although the user was not allowed to subsequently execute any requests against the database, this behavior was incorrect. This problem is fixed in Oracle Rdb V7.0. If a user is not authorized to access a database, then the sqlsrv_ associate service call always fails with a SQL_NO_PRIV (-1028), "%RDB-E-NO_PRIV, privilege denied by database facility" error. o The MAX_CONNECTIONS dispatcher attribute was a dynamic attribute. The Oracle SQL/Services monitor process uses the MAX_ CONNECTIONS and MAX_CLIENT_BUFFER_SIZE dispatcher attributes to calculate process quotas before starting a dispatcher process. Although the MAX_CLIENT_BUFFER_ SIZE attribute was always a nondynamic attribute, in versions of Oracle SQL/Services previous to V7.0, the MAX_CONNECTIONS attribute was a dynamic attribute. Therefore, it was possible to dynamically increase the number of client connections for a dispatcher. This could result in the dispatcher exceeding one or more process quotas causing it to drop client network connections. The MAX_CONNECTIONS attribute is now a nondynamic attribute so it is now necessary to restart the dispatcher for a change to this attribute to take effect. Therefore, the new dispatcher process will be created with the correct process quotas. <> o Dispatcher did not return SQLSRV_ERREXEABT (-2035) if an executor process failed. In versions of Oracle SQL/Services prior to V7.0 on Digital UNIX, if a client connected to a service, the monitor started a new executor process for the client, and the executor process failed to start, then the dispatcher incorrectly returned a SQLSRV_NO_PRCAVL (- 2033) error to the client. Software Errors Fixed 2-9 This problem is fixed in V7.0. In this situation, the dispatcher logs the reason for the failure in the dispatcher log file and returns the SQLSRV_ERREXEABT (-2035) error to the client. <> o The sqlsrv_sqlda2_ref_data service call did not return the correct value for the length of a generalized number with a nonzero scale factor. In Oracle SQL/Services Versions 6.1 and earlier, the sqlsrv_sqlda2_ref_data API service would return the scale factor in the high-order word of the length for a generalized number, thus resulting in a large value for a generalized number with a nonzero scale factor. This problem is fixed in V7.0. The length value returned by the sqlsrv_sqlda2_ref_data routine now represents the correct length of the column. o Estimated result table cardinality was not returned in SQLERRD[2] by the sqlsrv_open_cursor service call. Upon successful completion of an open cursor request for a table cursor, dynamic SQL stored the estimated result table cardinality and the estimated number of I/Os into the SQLERRD[2] and SQLERRD[3] fields of the SQLCA, respectively. Versions of Oracle SQL/Services previous to V7.0 returned the estimated number of I/Os in SQLERRD[2], but did not return the estimated result table cardinality in SQLSRRD[3]. This problem is fixed in V7.0. o Dispatcher did not handle ASSOCIATE message split across multiple TCP/IP packets. In versions of Oracle SQL/Services prior to V7.0, the dispatcher dropped the network link from a client using TCP/IP if the network delivered the single ASSOCIATE message to the dispatcher in multiple network packets. This problems is fixed in V7.0. 2-10 Software Errors Fixed 2.1.2 Problems Fixed in Oracle SQL/Services V7.0 Clients The following known problems found in Oracle SQL/Services V6.1 clients and previous releases are fixed in the V7.0: o Client sent an inappropriate message to the executor if the client aborted a batch-execute request. In versions of Oracle SQL/Services prior to V7.0, the Oracle SQL/Services client API sent an inappropriate message to the executor if the client application called sqlsrv_execute with the SQLSRV_EXE_ABORT flag and if writing the ABORT_MESSAGE tag completely filled the message buffer. The inappropriate message caused all versions of the Oracle SQL/Services executor to bugcheck. This problem is fixed in V7.0. o TCP/IP packet split problem occurred during fetch_many operations. Oracle SQL/Services clients, in versions prior to Oracle SQL/Services V6.1 ECO02, a timing related problem caused packet split errors during fetch_many operations. When TCP/IP is used as a transport, Oracle SQL/Services messages are prefixed with a message length. Previous versions of the Oracle SQL/Services clients did not correctly handle this message length being split by TCP /IP. This problem is fixed in Oracle SQL/Services V7.0 for all Oracle SQL/Services client platforms. o Macintosh client API had a TCP/IP packet split problem. In versions of Oracle SQL/Services Macintosh client API prior to V7.0, a TCP/IP packet split problem might have occurred. This client may have reported the following errors when the problem was encountered: SQLSRV_PRSERR - Parsing error (-2007). Called Failed - Returned by Server (-1). Bus Error - Macintosh Client needs to be rebooted. ________________________ Note ________________________ These errors may not have been the only problems encountered. The client may have experienced other Software Errors Fixed 2-11 unknown side effects. ______________________________________________________ This error could have occurred randomly and was timing related depending upon the activity on the network, the class of machine that the Oracle SQL/Services database server was running under and the size of the network packets that were being transferred. The problem arouse when a data buffer was split across two network packets. The Macintosh client API incorrectly determined the number of bytes read from a socket during a TCP/IP read operation. This problem is fixed in V7.0. o Client sent an extra row at the end of a batch-execute request if the END_OF_MESSAGE tag did not fit in the buffer. In versions of Oracle SQL/Services prior to V7.0, the Oracle SQL/Services client API incorrectly duplicated the last row of a batch-execute request if the last row exactly filled the buffer. This made it necessary for the END_OF_MESSAGE tag to be sent in a subsequent packet. This problem is fixed in V7.0. o Macintosh clients generated bus errors when referencing SQLDA columns for a CALL statement. In versions of Oracle SQL/Services prior to V7.0, it was possible for a call to sqlsrv_sqlda[2]_ref_data or sqlsrv_sqlda[2]_unref_data to cause a bus error if the prepared statement was a CALL statement and sqlsrv_ allocate_sqlda[2]_data had not been called to allocate the SQLDATA and SQLIND memory for the SQLDA. This problem is fixed in V7.0. o Oracle SQL/Services client API services returned an SQLSRV_INVSQLDA (-2006) error when accessing a SQLDA2 with more than 60 columns. In versions of Oracle SQL/Services prior to V7.0, when using a client API that uses 16-bit integers, such as the MS Windows 3.1 dynamic link library (DLL) and the Macintosh ThinkC libraries, many Oracle SQL/Services 2-12 Software Errors Fixed client API services returned an SQLSRV_INVSQLDA (-2006) error when accessing a SQLDA2 with more than 60 columns. This problem is fixed in V7.0. However, due to addressing limitations, the maximum number of SQLDA2 columns supported in an SQLDA with the MS Windows 3.1 16-bit FAR model DLL is 120. o Client did not handle ASSOCIATE-ACK, and associate ERROR messages split across multiple TCP/IP packets. In versions of Oracle SQL/Services prior to V7.0, if the network delivered the single ASSOCIATE-ACK or associate ERROR message to the client in multiple network packets, sqlsrv_associate returned a SQLSRV_PRSERR (-2007) error to the client application. This problem is fixed in V7.0. o Logging problems. The following problems with the Oracle SQL/Services logging facility are fixed in V7.0: - Support for the DEC Multinational Character Set (DEC MCS). In versions of Oracle SQL/Services prior to V7.0, the Oracle SQL/Services logging facility considered all 8-bit character values to be nonprintable. This problem is fixed in V7.0. The Oracle SQL/Services logging facility now considers any character from the DEC Multinational Character Set to be printable. Note that on some client platforms, some of these characters may not be considered printable depending on the editor or word processor and the font you are using. - Scrambled password displayed in the log file. The Oracle SQL/Services client API scrambles the password before building and optionally logging the ASSOCIATE message. In versions of Oracle SQL/Services prior to V7.0, the scrambled password would occasionally be displayed in the log file if the scrambled characters were considered printable. Software Errors Fixed 2-13 This problem is fixed in V7.0. Now that the logging facility supports the DEC MCS, scrambled passwords would be displayed much more frequently and so are now always displayed as . For example: PROTOCOL LEVEL LOG CLIENT: write (logonly) at 16:15:59 on 20-May-1996 ----PACKET ID: 1, PACKET SEQUENCE: 0 --------SQLSRV_ASSOCIATE ------------CLIENT PROTOCOL VERSION ----------------len: 2, value: 14 ------------USERNAME ----------------SQLSRV_ASCII_STRING, len: 8 --------------------len: 8, value: sqstest1 ------------PASSWORD ----------------SQLSRV_VARCHAR, len: 8 --------------------len: 10, value: . . . - SQLDATA values displayed if NULL indicator was set. In versions of Oracle SQL/Services prior to V7.0, the logging facility ignored the SQLIND NULL indicator and displayed stale data from a previous request if the NULL indicator was set to -1. This problem is fixed in V7.0. If the NULL indicator is set to -1, the SQLDATA value is not displayed. For example: --------PARAMETER MARKER SQLDA ------------SQLDA: SQLD 15 ----------------[0].SQLTYPE: SQLSRV_GENERALIZED_NUMBER, SQLIND: 0 --------------------len: 3, value: 222 ----------------[1].SQLTYPE: SQLSRV_VARCHAR, SQLIND: -1 --------------------len: 0, value: . . . - Parameter marker SQLDA displayed if the execute flag was set to SQLSRV_EXE_WO_DATA or SQLSRV_EXE_ABORT. 2-14 Software Errors Fixed In versions of Oracle SQL/Services prior to V7.0, the logging facility always displayed the parameter marker SQLDA passed to sqlsrv_execute or sqlsrv_ execute_in_out. However, if the execute flag was set to SQLSRV_EXE_WO_DATA or SQLSRV_EXE_ABORT, then there was no data and the values displayed were stale data from a previous call. This problem is fixed in V7.0. The parameter marker SQLDA is no longer displayed if the executor flag is set to SQLSRV_EXE_WO_DATA or SQLSRV_EXE_ABORT. For example: ROUTINE LEVEL LOG at 17:18:40 on 20-May-1996 ----SQLSRV_EXECUTE --------STATEMENT ID ------------1001238 --------EXECUTE_FLAG: SQLSRV_EXE_WO_DATA - Length and scale or type metadata were not correctly displayed. In versions of Oracle SQL/Services prior to V7.0, the logging facility incorrectly displayed the metadata information for ANSI DATE, TIME, TIMESTAMP, and INTERVAL data types. These problems are fixed in V7.0. For example: Software Errors Fixed 2-15 ROUTINE LEVEL LOG at 17:18:39 on 20-May-1996 ----PARAMETER MARKER SQLDA --------SQLDA: SQLD 9 --------[0].SQLTYPE: SQLSRV_ASCII_STRING, SQLLEN: 25 ------------SQLNAME: F_CHAR_25 --------[1].SQLTYPE: SQLSRV_VARCHAR, SQLLEN: 17 ------------SQLNAME: F_VARCHAR_17 --------[2].SQLTYPE: SQLSRV_GENERALIZED_NUMBER, SIZE 4, SCALE 0 ------------SQLNAME: F_TINYINT --------[3].SQLTYPE: SQLSRV_GENERALIZED_NUMBER, SIZE 7, SCALE 2 ------------SQLNAME: F_SMALLINT_2 --------[4].SQLTYPE: SQLSRV_GENERALIZED_DATE, SIZE 17, TYPE 0 ------------SQLNAME: F_DATE_VMS --------[5].SQLTYPE: SQLSRV_GENERALIZED_DATE, SIZE 17, TYPE 1 ------------SQLNAME: F_DATE_ANSI --------[6].SQLTYPE: SQLSRV_GENERALIZED_DATE, SIZE 17, TYPE 2 ------------SQLNAME: F_TIME_1 --------[7].SQLTYPE: SQLSRV_GENERALIZED_DATE, SIZE 17, TYPE 3 ------------SQLNAME: F_TIMESTAMP_2 --------[8].SQLTYPE: SQLSRV_INTERVAL, SIZE 22, TYPE 10 ------------SQLNAME: F_DAY_9_SEC - Logging facility incorrectly logged signed and unsigned 16-bit values. In versions of Oracle SQL/Services prior to V7.0, on some client platforms, the Oracle SQL/Services logging facility would treat all 16-bit integer values as signed values. This problem is fixed in V7.0. All 16-bit integer values are now treated as either signed or unsigned values depending on the parent tag. o Sample did not handle all data types and executable statements with output arguments. In versions of Oracle SQL/Services prior to V7.0, the sample application did not handle the ANSI DATE, TIME, TIMESTAMP, or INTERVAL data types. This problem is fixed in V7.0. The sample application now illustrates how the SQLDA2 ANSI DATE, TIME, TIMESTAMP, or INTERVAL data types can be accessed using a standard SQLDA. 2-16 Software Errors Fixed In versions of Oracle SQL/Services prior to V7.0, the sample application incorrectly handled executable statements with an output argument, such as a CALL or singleton-SELECT statement. This problem is fixed in V7.0. The sample application now uses the SQLERRD[1] field of the SQLCA to determine the statement type and how to process it using sqlsrv_ execute or sqlsrv_open_cursor/fetch.../close_cursor. o Oracle SQL/Services protocol had logging problems. Oracle SQL/Services V6.1 and earlier would occasionally encounter a parse error (-2007) or produce an access violation while logging the protocol for write messages. This problem is fixed in V7.0. o IVP incorrectly passed the DECnet node name to the IVP for the TCP/IP test run. In versions of Oracle SQL/Services prior to V7.0, the Oracle SQL/Services IVP incorrectly passed the DECnet node name to the IVP for the TCP/IP test run. In many cases, the DECnet node name and the TCP/IP host name are the same, but not always. This problem is fixed in V7.0. The IVP now correctly passes the DECnet node name to the IVP for the DECnet test run, and the tcp host name to the IVP for the TCP /IP test run. o Documentation Error in the V6.1 Release Notes: Digital UNIX Client API Does Not Support Direct Manipulation of the SQLCA and SQLDA Structures. It was documented in the Oracle SQL/Services V6.1 Release Notes that direct manipulation of the SQLCA and SQLDA structures was not supported for the Digital UNIX client API and that Oracle SQL/Services routines must be used to manipulate these structures. This statement is incorrect. This was never a problem in V6.1. Direct manipulation of the SQLCA and SQLDA structures is supported for the Digital UNIX client API. <> Software Errors Fixed 2-17 3 _________________________________________________________________ Known Problems, Restrictions, and Other Notes This chapter describes problems and restrictions relating to Oracle SQL/Services Version V7.0. ________________________ Note ________________________ This chapter contains information on existing problems and software restrictions that were documented in Oracle SQL/Services V6.1, V6.0, and V5.1. ______________________________________________________ 3.1 Oracle SQL/Services Known Problems and Restrictions for V7.0 This section contains known problems and restrictions for Oracle SQL/Services for V7.0. 3.1.1 Oracle SQL/Services Manager GUI Restrictions and Known Problems The following information describes Oracle SQL/Services Manager graphical user interface (GUI) restrictions and known problems: o Only one copy of the Oracle SQL/Services Manager GUI can run on a PC. Only one copy of the Oracle SQL/Services Manager GUI can be run on a given PC at any one time. o Missing icons in the Oracle SQL/Services Manager tree view (Win31). The Oracle SQL/Services Manager GUI uses a tree view to display the servers to which you are connected, and to display their dispatchers and services. Each object in the tree should also have an icon, similar to the icons in the toolbar buttons, displayed to its left. Known Problems, Restrictions, and Other Notes 3-1 With Windows V3.1, these icons are not displayed when using 64k colors with certain Video Cards. If the icons do not appear in the tree view, reset the colors to use 16 color, or 256 color. 3.1.2 Oracle SQL/Services V7.0 Server Restrictions and Known Problems The following information describes Oracle SQL/Services V7.0 server restrictions and known problems: o Problems with installing Oracle Rdb V6.1 after installing Oracle SQL/Services V7.0 or higher. The following problems occur when you install Oracle Rdb V6.1 after installing Oracle SQL/Services V7.0 or higher - SYS$SHARE:sqlsrv$mod61.exe or SYS$SHARE:sqlsrv$mod.exe may be replaced. Oracle SQL/Services implements database services using a number of new SQL module language procedures. In order to use database services with Oracle Rdb V6.1 databases, the Oracle SQL/Services V7.0 installation procedure updates the Oracle SQL/Services SQL module procedure shared image for Oracle Rdb V6.1: SYS$SHARE:sqlsrv$mod61.exe or SYS$SHARE:sqlsrv$mod.exe. If you install Oracle Rdb V6.1 ECO01 or earlier after installing Oracle SQL/Services V7.0 or higher, the Oracle SQL/Services SQL module procedure shared image will be overwritten and errors occur. If Oracle Rdb V6.1 (no ECO) is reinstalled after Oracle SQL/Services V7.0 or higher is installed, the following errors occur when you attempt to start a database service: 3-2 Known Problems, Restrictions, and Other Notes ------------EVENT BEGIN: EVENT_LOG at Tue Jul 23 1996 15:17:47.250------------- %SQLSRV-I-EVENT_LOG, event logged at line 739 in file SRVSQLINIT.C;1 %SQLSRV-E-SHRIMGLOOKUPERR, Error looking up symbol: SQLSRV$MOD_LWC_CONNECT_IMP in shared image: SYS$COMMON:[SYSLIB]SQLSRV$MOD61.EXE %SQLSRV-E-ERROR_TEXT, Error text: %LIB-E-KEYNOTFOU, key not found in tree %SQLSRV-F-BADSQLSRVINSTAL, Required SQL/Services entry-point not found %SQLSRV-E-EXECINITFAILED, Executor initialization failed; process terminating ------------EVENT END : EVENT_LOG at Tue Jul 23 1996 15:17:47.275------------- If Oracle Rdb V6.1 ECO01 is installed after Oracle SQL/Services V7.0 or higher is installed, the following errors occur when you attempt to connect to a database service: ------------EVENT BEGIN: EVENT_LOG at Wed Jul 24 1996 15:46:55.463------------- %SQLSRV-I-EVENT_LOG, event logged at line 2217 in file SRVEXE.C;1 %SQLSRV-E-LWCCONNERRUSER, Error creating a SQL connect for username: USERNAME %SQL-F-ARGCOUNT, Procedure SQLSRV$MOD_LWC_CONNECT_IMP expected 5 parameters, was passed 4 ------------EVENT END : EVENT_LOG at Wed Jul 24 1996 15:46:55.481------------- - SYS$SHARE:sql$setver.com may be replaced. Oracle SQL/Services uses new logical names defined by SYS$SHARE:sql$setver.com to determine the version of SQL being run, and to find the correct Oracle SQL/Services SQL module procedure shared image. If an older version of sql$setver.com is found on the system, the Oracle SQL/Services V7.0 installation procedure updates the sql$setver.com file. If you install Rdb V6.1 or any ECO of Oracle Rdb V6.1 after installing Oracle SQL/Services V7.0 or higher, SYS$SHARE:sql$setver.com may be replaced with an older version and the following errors may occur when a service is started: ------------EVENT BEGIN: EVENT_LOG at Thu Jul 25 1996 11:04:36.378------------- %SQLSRV-I-EVENT_LOG, event logged at line 863 in file SRVSQLINIT.C;1 %SQLSRV-W-SQLVERNOTFOUND, Could not determine SQL version; results unpredictable ------------EVENT END : EVENT_LOG at Thu Jul 25 1996 11:04:36.518------------- Known Problems, Restrictions, and Other Notes 3-3 In addition, if the Oracle SQL/Services service sets its SQL version to a version of SQL that was installed as multiversion, the following errors may occur when a service is started: ------------EVENT BEGIN: EVENT_LOG at Thu Jul 25 1996 11:04:36.548------------- %SQLSRV-I-EVENT_LOG, event logged at line 739 in file SRVSQLINIT.C;1 %SQLSRV-E-SHRIMGLOOKUPERR, Error looking up symbol: SQLSRV$MODCLSCRS in shared i mage: SQLSRV$MOD %SQLSRV-E-ERROR_TEXT, Error text: %LIB-E-ACTIMAGE, error activating image PENINE$DKA0:[SYS0.SYSCOMMON.][SYSLIB]SQL SRV$MOD.EXE; -RMS-E-FNF, file not found %SQLSRV-F-SQLNOTINSTALLED, Specified SQL version is not installed %SQLSRV-E-EXECINITFAILED, Executor initialization failed; process terminating ------------EVENT END : EVENT_LOG at Thu Jul 25 1996 11:04:36.578------------- To correct either of these problems you can reinstall Oracle SQL/Services V7.0 or higher, or you can extract the correct files from the Oracle SQL/Services V7.0 kit saveset. The following examples illustrate the procedure for extracting files from the Oracle SQL/Services OpenVMS Alpha Multiversion kit: ! Extract SQL$SETVER.COM and put it in SYS$COMMON:[SYSLIB] $BACKUP/SELECT=(sql$setver.com) - SQLSRVAM070.A/SAVE - SYS$COMMON:[SYSLIB]*/LO ! Extract SQLSRV$MOD.EXE and put it in SYS$COMMON:[SYSLIB]. Extract this ! file only if Rdb 6.1 or SQL 6.1 is installed standard. $BACKUP/SELECT=(sqlsrv$mod.exe) - SQLSRVAM070.A/SAVE - SYS$COMMON:[SYSLIB]*/LO ! Extract SQLSRV$MOD61.EXE and put it in SYS$COMMON:[SYSLIB]. Extract this ! file if Rdb 6.1 or SQL 6.1 is installed multiversioned. $BACKUP/SELECT=(sqlsrv$mod61.exe) - SQLSRVAM070.A/SAVE - SYS$COMMON:[SYSLIB]*/LO <> o Locked configuration files during an installation. 3-4 Known Problems, Restrictions, and Other Notes The Oracle SQL/Services V7.0 installation procedure deletes any pre-existing configuration files because they will not work with Oracle SQL/Services V7.0. On OpenVMS systems, before deleting any configuration files, the highest generation of the following configuration files, if found, are copied to the same location with ".SAV" as the file extension: - SYS$SPECIFIC:[SYSMGR]sqlsrv_config_file[70].dat - SYS$COMMON:[SYSMGR]sqlsrv_config_file[70].dat - The file to which the SQLSRV_CONFIG_FILE[70] logical name points On Digital UNIX systems, if an existing configuration file is found, you are prompted as to whether you want the old configuration file deleted or whether you want to recreate the configuration file using the old file name. If any of these configuration files is locked at the time of the installation, the installation fails with a copy error. Although the installation procedure stops any running Oracle SQL/Services server, any running SQLSRV_MANAGE[70] sessions will have a configuration file opened and locked. If this occurs, please exit SQLSRV_MANAGE[70] and retry the installation. o Database authorization for database services must be specified as the service owner for Oracle Rdb V6.0 or earlier databases or for the Rdb Distributed Technology Suite (formerly DEC DB Integrator). In V7.0, Oracle SQL/Services on OpenVMS systems added the ability to define database services with database access authorization set to the connect user name. In versions of Oracle SQL/Services previous to V7.0, database services always accessed the database using the service owner user name. For database services, database access using the connect user name is only available for services that attach to Oracle Rdb V6.1 or higher databases. Database services that attach to Oracle Rdb V6.0 or earlier databases, or for the Rdb Distributed Technology Suite (formerly DEC DB Integrator) databases must specify database authorization as the service owner for database Known Problems, Restrictions, and Other Notes 3-5 services. This restriction does not apply to universal services (those services not preattached to a database). o Do not kill Oracle SQL/Services processes Under certain circumstances, the entire Oracle SQL/Services server shuts down if an Oracle SQL/Services dispatcher or executor is abnormally terminated. You should never use the DCL STOP/ID command on OpenVMS systems or the kill command on Digital UNIX systems to stop or kill an Oracle SQL/Services dispatcher or executor process. The Oracle SQL/Services system management command SHUTDOWN DISPATCHER or SHUTDOWN SERVICE should be used to stop dispatchers and executors. If an executor does not terminate after issuing the SHUTDOWN SERVICE command, or if you do not want to shut down the entire service, the Oracle SQL/Services system management command, KILL EXECUTOR, should be used instead. Note that the RMU Close command can have the same effect as the STOP/ID or kill command by terminating Oracle SQL/Services executors attached to the database being closed. Before using the RMU Close command, ensure that no Oracle SQL/Services executors currently have the database open. Any executors you find that do have the database open should be terminated with either the Oracle SQL/Services system management command SHUTDOWN SERVICE or the KILL EXECUTOR command. o Oracle SQL/Services does not support columns that have a negative scale factor In versions of Oracle SQL/Services prior to V7.0, when preparing a statement containing a reference to a column with a negative scale factor, the executor incorrectly calculates the amount of memory required for the SQLDA and SQLDATA structures. This results in the executor bugchecking with the error message "SQL Services Internal Error: 3, %SQLSRV-F-INTERR, Internal Error: -29460". In Oracle SQL/Services V7.0, the executor incorrectly calculates the amount of memory required for the SQLDATA structure. This results in data from columns with a negative scale factor being truncated. However, in this situation, no error message is written to the 3-6 Known Problems, Restrictions, and Other Notes executor log file nor is an error returned to the client application. o Executor bugchecks if a pre-V7.0 Oracle SQL/Services client API sends an inappropriate batch-execute abort message. In versions of Oracle SQL/Services prior to V7.0, the Oracle SQL/Services client API sends an inappropriate message to the executor if the client application calls sqlsrv_execute with the SQLSRV_EXE_ABORT flag, and if writing the ABORT_MESSAGE tag completely fills the message buffer. The inappropriate message causes all versions of the Oracle SQL/Services executor to bugcheck. For example, the Oracle SQL/Services V7.0 executor will bugcheck with a message similar to the following: ------------EVENT BEGIN: EVENT_LOG at Tue May 21 1996 18:41:44.323------------- %SQLSRV-I-EVENT_LOG, event logged at line 831 in file SRVUTL.C;1 %SQLSRV-F-INTERR, Internal error -2011 in SQL/Services executor version V7.0-00 at line 1833 in module SRVEXEMAIN %SQLSRV-E-ERROR_TEXT, Error text: invalid packet sequence number 1, expected 0 ------------EVENT END : EVENT_LOG at Tue May 21 1996 18:41:44.351------------- ________________________ Note ________________________ This problem is fixed for the V7.0 Oracle SQL/Services client API (see Section 2.1.2, but not for any pre- V7.0 Oracle SQL/Services client API using an Oracle SQL/Services V7.0 executor. ______________________________________________________ o Account must have a matching UIC identifier to use Oracle Rdb V6.1 with a database service that has database authorization set to connect user name. If a client application attempts to connect to a database service configured to use Oracle Rdb V6.1 that has database authorization set to connect user name, then the sqlsrv_associate call fails with a SQL_ RDBERR (-1), "%RDB-F-AUTH_FAIL, authentication failed for user !AC" error if there is no identifier for the user account's UIC or if the name of the UIC identifier does not match the username. <> Known Problems, Restrictions, and Other Notes 3-7 o Do not shut down or restart the SQLSRV_MANAGE system management service. If you shut down or restart the SQLSRV_MANAGE system management service using either the SQLSRV_MANAGE utility or the Oracle SQL/Services Manager GUI, then subsequent attempts to connect to the server are rejected and you render the server unmanageable. If you do accidentally shut down or restart the SQLSRV_ MANAGE service, then you must find and kill the Oracle SQL/Services monitor process, then restart the server. o Problem when the keyword "autoconnect" or "autostart" is abbreviated as "auto". The SQLSRV_MANAGE syntax now includes an AUTOCONNECT and an AUTOSTART attribute; therefore, the abbreviation "AUTO" is not unique. If the abbreviation "AUTO" is used, a misleading syntax error is generated. For example: SQLSRV> create service v61 auto on sql version 6.1 owner 'sqlsrv$deflt'; syntax error at ''Owner', required parameter not specified' o Monitor log files have different file specifications if the server fails to start compared to a successful server startup operation. If the monitor process detects an error early on during server startup, then you need to look at different monitor log files to determine the reason for the failure. In this situation, look for errors in the following log files in the /tmp directory: sqlsrv_mon_00_err.log sqlsrv_mon_00_out.log Note that the monitor log files are renamed as follows in the /tmp directory when the server starts successfully: SQLSRV_70000_err.log SQLSRV_70000_out.log <> o Oracle SQL/Services management utilities do not prevent multiple dispatchers with the same port IDs. 3-8 Known Problems, Restrictions, and Other Notes Oracle SQL/Services allows you to define multiple dispatchers, each listening on different network ports. Currently, the SQLSRV_MANAGE and the Oracle SQL/Services Manager GUI do not ensure that multiple dispatchers do not use the same port numbers or names. If multiple dispatchers are defined to use the same ports, the second dispatcher to be started fails. o Database service attached to a remote database does not know if the database is closed. It is possible for Oracle SQL/Services database services to be preattached to a remote database. For example, the payroll service defined below attaches to the database "payroll" on node "REMOTE". create service payroll autostart on reuse session sql version 7.0 attach 'filename REMOTE::payroll' owner 'payrollaccnt' database authorization service owner min_executors 5 max_executors 5 If the payroll database on node REMOTE is closed, the Oracle SQL/Services payroll service has no way of knowing that the database has been closed. The payroll service continues to run, even though it is no longer attached to the database. The service is useless and must be shutdown and restarted after the database is reopened. Any clients attached to the service while it is in this state get a SQLCODE of -1 with the following errors when they attempt to access the database: %RDB-F-IO_ERROR, input or output error -SYSTEM-F-LINKABORT, network partner aborted logical link All Oracle SQL/Services services that are preattached to a remote database should be shut down before the database is closed. If this is not possible, there is a workaround for database services defined to attach to Oracle Rdb V6.1 or higher databases. Rather than defining session reusable database services, you can define a transaction reusable database service with CLIENTS_PER_EXECUTOR set to 1. Known Problems, Restrictions, and Other Notes 3-9 create service payroll autostart on reuse session sql version 7.0 attach 'filename REMOTE::payroll' owner 'payrollaccnt' database authorization service owner min_executors 5 max_executors 5 clients_per_executor 1 The service definition previously shown gives you essentially the same behavior as the previous session reusable database service. However, Oracle SQL/Services executes a "get diagnostics ? = transaction_active" statement to detect the end of a transaction for transaction reusable services. Because this requires a call to the Oracle Rdb engine, it fails and Oracle SQL/Services bugchecks and shuts down the executor. If this brings the executor count below the MIN_EXECUTORS value defined for the service, the Oracle SQL/Services monitor attempts to create a new executor process. If the monitor fails to start a new executor process after two attempts, it shuts down the service. Note that this workaround generates executor bugcheck dumps that need to be cleaned up. o Log and bugcheck dump file path server attributes are ignored on OpenVMS systems. The log and bugcheck dump file path server attributes are ignored on OpenVMS systems. Monitor and dispatcher log and bugcheck dump files are always written to SYS$MANAGER, while executor log files are always written to the default directory of the service owner's account. For a universal service with database authorization set to the connect user name, executor bugcheck dump files are written to the default directory of the connect user name; for all other types of service, the executor bugcheck dump files are written to the default directory of the service owner's account. 3-10 Known Problems, Restrictions, and Other Notes ________________________ Note ________________________ The quickest way to locate a bugcheck dump file for a monitor, dispatcher, or executor is to check the monitor log file. The monitor log file describes the location of the dispatcher and executor log files and the location, if any, of any monitor bugcheck dump files. The dispatcher and executor log files describe the location, if any, of any dispatcher and executor bugcheck dump files, respectively. _<>___________________________________________________ o Process startup fails due to unhandled errors in systemwide OpenVMS login procedure. All processes in the Oracle SQL/Services server environment on OpenVMS are created running the SYS$SYSTEM:loginout image with a process-specific command procedure as SYS$INPUT. Because the loginout image is used to create the process, the systemwide login procedure will be executed by the loginout image during process creation. If this procedure fails for some reason, then the Oracle SQL/Services process will fail to start. By default, any DCL command or image that completes with a failure status with a severity level of error or fatal can cause the procedure to fail unless it is handled using the DCL ON or SET NOON commands. All Oracle SQL/Services processes start by executing the following DCL commands during process creation: $ DELETE/SYMBOL/ALL $ VRFY_SAVE = F$VERIFY(1) $ DELETE :[directory]SQS__.COM; $ DEFINE SQS$DBSERVER TRUE $ DEFINE SYS$LOGIN ":[directory]" $ SET DEFAULT SYS$LOGIN $ DEFINE SYS$SCRATCH ":[directory]" If an Oracle SQL/Services process fails before executing these commands, please review the systemwide login procedure to determine the reason for the failure. <> o SPX links do not disconnect in some error situations. Known Problems, Restrictions, and Other Notes 3-11 Sequenced Packet Exchange (SPX) links may not terminate in certain error situations including when a user enters a bad password. This can lead to a situation where a service might seem to have too many active users for new users to use the service. If you are using SPX with this release (V7.0), consider padding the number of users allowed on a service and on the dispatcher to minimize the effects of this problem. These links can be cleared only by shutting down the dispatcher and restarting it. <> o DBSRC_FILE service attribute is not supported on OpenVMS. See Section 1.2 for more information on how to specify an rdb$client_defaults.dat file on OpenVMS. <> 3.1.3 Oracle SQL/Services V7.0 Client Restrictions and Known Problems The following information describes Oracle SQL/Services V7.0 client restrictions and known problems: o Oracle SQL/Services OpenVMS client is now compiled with DEC C The Oracle SQL/Services client shared image for OpenVMS is now compiled using DEC C. The options file provided by Oracle SQL/Services for linking client applications has changed. It used to include SYS$LIBRARY:vaxcrtl$api /share. It now includes SYS$LIBRARY:sqlsrv$api/share. If you want to relink a client application that was compiled with VAX C, you must create an options file that specifies SYS$LIBRARY:vaxcrtl/share and link against this new options file as well as SYS$LIBRARY:sqlsrv$api.opt. o Use a special jacket header file when calling the Oracle SQL/Services API from C++. The Oracle SQL/Services header files, sqlsrv.h, sqlsrvca.h, and sqlsrvda.h, do not provide built-in support for use with the C++ programming language. However, by providing a jacket header file, you may call the Oracle SQL/Services API from C++ as you would 3-12 Known Problems, Restrictions, and Other Notes from C. To include the Oracle SQL/Services header files in a C++ application, create the following header file, called sqlsrv.hxx, and #include it in your application program: // // Define VMS if compiling on OpenVMS to pick up the $ versions of // the service names. // #ifdef __VMS #ifndef VMS #define VMS #endif #endif // // Include the headers files using C, not C++. No need to include // sqlsrvca.h or sqlsrvda.h unless the application directly accesses // the SQLCA and SQLDA structures. // extern "C" { #include // #include // #include } o Client enters nonrecoverable error state if a statement with no parameter markers is executed using batched execution. If an application executes a prepared statement using the SQLSRV_EXE_BATCH flag, but the statement does not contain any parameter markers, the statement is incorrectly executed as if the SQLSRV_EXE_W_DATA flag had been specified. That is, the Oracle SQL/Services client API immediately sends an execute request message to the server to execute the statement. At this point, subsequent calls to any API routine, including sqlsrv_ execute_in_out and sqlsrv_execute, all fail with SQLSRV_ INTERR (-2011) or SQLSRV_MULTI_ACT (-2016) errors. Once the client API has entered this error state, only the sqlsrv_abort routine functions correctly. Therefore, client applications must not execute SQL statements Known Problems, Restrictions, and Other Notes 3-13 that do not contain parameter markers using batched execution. o Incorrect error message is returned if a client cancels batched execution. If an application calls sqlsrv_execute_in_out or sqlsrv_ execute with the execute flag set to SQLSRV_EXE_WO_ DATA before calling sqlsrv_execute_in_out or sqlsrv_ execute with the execute flag set to SQLSRV_EXE_BATCH, the client API incorrectly sends an execute request message to the server with no statement ID. Upon receipt of this message, the server returns an SQLSRV_INVSTMID (-2008) error back to the client with the following error message: %SQLSRV-F-INVSTMID, Invalid statement id: 0 In this situation, the SQLSRV_INVSTMID error may be ignored. o PATHWORKS for DOS and Windows (Windows 95 Release). In order to use the DECnet transport as a transport for Windows 95, use the following procedures: Install the Windows 95 Release of PATHWORKS for DOS and Windows Version 1.0A. Version 1.0A is the required version for the DECnet transport. Any Oracle SQL/Services client application that tries running against Version 1.0A will receive the following error: SQLSRV_DLL_ADDR_ERR (-2046). ________________________ Note ________________________ An additional patch is required to the PATHWORKS V1.0A kit. Call the Customer Support Center at Digital Equipment Corporation to obtain this patch. The Oracle ODBC Driver for Rdb will return the following error SQLSRV_DLL_ADDR_ERR (-2046). This means pwsock32.dll, a PATHWORKS dynamic link library, is missing a required routine. The name of the missing PATHWORKS routine is called SktEndNodeEnt. ______________________________________________________ 3-14 Known Problems, Restrictions, and Other Notes o Client disconnect does not abort running transaction for transaction reusable services. On long-running queries, users may expect that by rebooting the PC the query will be terminated. This is not the case for transaction reusable services. The query will continue until it is ready to send a response to the client. For session reusable services, the query will terminate. o Applications using clients shipped with Oracle SQL/Services Version 3.1 or earlier are not supported, but are not rejected. Associations from applications using clients shipped with Oracle SQL/Services Version 3.1 or earlier are not supported but are not rejected by the dispatcher. 3.1.4 Other Oracle SQL/Services Server for OpenVMS and Digital UNIX Restrictions and Known Problems The following information describes additional Oracle SQL/Services server for Digital UNIX and OpenVMS restrictions and known problems (where a restriction applies to only one platform, an icon denotes to which platform the restriction is applicable; when no platform specific icon is present, this means the restriction applies to all platforms): o LOCALE service attribute is not supported on OpenVMS. The LOCALE service attribute (CREATE SERVICE and ALTER SERVICE commands) is not supported on OpenVMS. <> o Oracle SQL/Services does not support an implicit attach using the SQL_DATABASE environment variable on Digital UNIX or an implicit attach using the SQL$DATABASE logical name on OpenVMS. Oracle SQL/Services does not support the use of the SQL_DATABASE SQL environment variable on Digital UNIX or the SQL$DATABASE logical name on OpenVMS to implicitly attach to a database. For example, for Digital UNIX, if you define the SQL_DATABASE SQL environment variable in a universal service's .dbsrc file, or for OpenVMS, if you define the SQL$DATABASE logical name, a client application must still issue Known Problems, Restrictions, and Other Notes 3-15 an explicit SQL ATTACH statement. For example, use ATTACH 'FILENAME SQL_DATABASE' for Digital UNIX or ATTACH 'FILENAME SQL$DATABASE' for OpenVMS, to attach to the database. If a client application connected to a universal service issues a DML statement before attaching to a database, then the executor will return a status code of -1, with an associated "%SQL-F-NODEFDB, There is no default database" error message. o Suggested maximum executors of at least 2 for a service. Many popular desktop tools make two connections to the Oracle SQL/Services server to do their work. For example, MS Access makes one connection initially and returns the list of tables. When the first request to reference a table is made, MS Access makes another connection to the Oracle SQL/Services server. If no executor is available, MS Access returns an error and suggests that you have a problem with your disk or network. Oracle Corporation recommends that you configure maximum executors of at least 2. o Decreasing the values for the MIN_EXECUTORS and MAX_ EXECUTORS arguments for a transaction reusable service. When the value for the MIN_EXECUTORS and MAX_EXECUTORS arguments for a transaction reusable service is increased using the ALTER SERVICE command, more executors are made available; however, when the values for the MIN_EXECUTORS and MAX_EXECUTORS arguments are decreased, the values are not changed dynamically. You must perform a SHUTDOWN SERVICE command followed by a START SERVICE command to make fewer executors available. o Problems that exist for NO_SERVICE and SVCNOTRUN error returns. Clients may see the NO_SERVICE error returned when the service exists, but has not been started. Clients may see the SVCNOTRUN (service not running) error when, in fact, the service does not even exist. o Some error messages are missing object names. 3-16 Known Problems, Restrictions, and Other Notes Some error messages from SQLSRV_MANAGE are intended to display the object name that is the source of the error. However, the name is lost and no name is displayed. o Active dispatcher and executor processes prevent the monitor from starting. In certain rare error conditions, it is possible for a dispatcher or executor process to remain active after a server is shut down manually or after a server bugchecks and shuts down automatically. If a dispatcher or executor process is active when a server is started, the monitor process fails with the following message in the monitor's bugcheck dump file: %DBS-F-BUGCHECK: in SQS_MON.C;1 at line 1244 Shared memory already exists - monitor startup failed In this situation, look for and stop any active dispatcher or executor processes as follows. On Digital UNIX Systems: Use the following commands to look for active dispatcher or executor processes: ps -e | grep sqlsrv_disp ps -e | grep sqlsrv_exec ps -e | grep rmu_exec Use the kill -9 command to kill any dispatcher or executor processes that are still active. <> On OpenVMS Systems: Use the following commands to look for active dispatcher or executor processes: $ SET PROCESS/PRIVILEGE=WORLD $ SHOW SYSTEM Use the STOP/ID= command to stop any dispatcher or executor processes that are still active. <> o Using the 'dbsmgr' user name as the service owner of a database service. Known Problems, Restrictions, and Other Notes 3-17 On Digital UNIX systems, an attribute of the 'dbsmgr' user name is that it has full access to all databases, whether or not access has been granted explicitly to the 'dbsmgr' user name. If you create a database service using the 'dbsmgr' user name as the service owner and with the database authorization attribute specified as the connect user name, any users who have been granted access to use the service will have full access to the database provided by the service, regardless of the access granted to each user within the database. For example, if a particular user has only select access on a single table when using an application such as interactive SQL, that same user would have full access to the entire database using the Oracle SQL/Services database service. Therefore, do not create database services using the 'dbsmgr' user name as the service owner and with the database authorization attribute specified as the connect user name unless you want to allow full access to the database to all users that have been granted access to the service. ________________________ Note ________________________ This special behavior applies only to the 'dbsmgr' user name. No other user names have any special database access rights. ______________________________________________________ Note that users who access a database service created with the database authorization attribute specified as the service owner always access the database under the service owner's user name. <> o Using a local Oracle Rdb catalog with the Oracle Rdb Distributed Technology Suite (formerely DEC DB Integrator) and Oracle SQL/Services for Digital UNIX. Outside the Oracle SQL/Services environment, the SQL application (the user program) runs in a client process while the database engine, either Oracle Rdb or the Oracle Rdb Distributed Technology Suite (formerely DEC DB Integrator), runs in a separate server process. 3-18 Known Problems, Restrictions, and Other Notes Within the Oracle SQL/Services environment, the SQL application (the Oracle SQL/Services executor program) and the database engine both run in a single process for optimal performance. To use an Oracle Rdb catalog with the Oracle Rdb Technology Suite and Oracle SQL/Services, the Oracle Rdb Technology Suite engine must run in a separate server process from the Oracle SQL/Services executor. This happens automatically if the catalog is on a remote node. To use a local catalog, you must specify the local node name, together with a user name and a password, in the attach string, as follows: ATTACH ' FILENAME ::/TYPE=DBI/DBNAME="" USER ''local_user_name'' USING ''local_password'' ' <> o Where to locate the shared memory backing file. The shared memory backing file must be on a local file system where the server is running. It cannot be on a remotely served file system, such as an Network File System (NFS). <> o Some failures during process startup are not logged. For example, if a required shared object library cannot be found when the monitor tries to start a dispatcher or an executor process, no error is logged. This problem can be diagnosed by logging in under the 'dbsmgr' account and attempting to run either the sqlsrv_disp or sqlsrv_exec images or both images. If a loader error is returned or some other image activation error, address that problem. If a bugcheck is returned from the component, then the image activated correctly. <> o Log and lock files are not automatically cleaned up. Known Problems, Restrictions, and Other Notes 3-19 Log and lock files for the various Oracle SQL/Services components are created when the server is started. These files are not automatically cleaned up. Typically, they will be overwritten in a later invocation of the server. However, if a component is dropped, then log and lock files will persist unused. Log and lock files may be removed manually when the Oracle SQL/Services server is not running. <> o Problems that exist when creating .log files in the LOG_ PATH directory. If the monitor cannot rename its log files to the directory specified by the server's LOG_PATH argument, then the monitor will start, but the system will not be fully operational. An error similar to the following will be logged to the sqs_mon_out.log file in the /tmp directory: ------------EVENT BEGIN: ERROR_LOG at Mon Jan 23 13:47:19.046 1995------------ %DBS-I-ERROR_LOG, error logged at line 2349 in file sqs_mon.c %DBS-E-SM_RENAME_ERR, Error renaming file /tmp/sqs_mon_out.log to /tmp/sqs_lt/logs/SQS_DEFAULT0004_out.log %DBS-E-UNIX_ERROR_TEXT, Error text: Permission denied ------------EVENT END : ERROR_LOG at Mon Jan 23 13:47:19.047 1995------------ <> o Problems that exist when creating .lock files in the LOCK_PATH directory. If the monitor cannot create its .lock file in the directory specified by the server's LOCK_PATH argument, then the monitor cannot start up correctly. An error similar to the following will be logged to the sqs_ sqlsrv_mon_70_out.log file in the /tmp directory: ------------EVENT BEGIN: ERROR_LOG at Mon Jan 23 13:47:19.046 1995------------ %DBS-I-ERROR_LOG, error logged at line 819 in file evt.c %DBS-E-FLOBCREATERR, Error on system service call ------------EVENT END : ERROR_LOG at Mon Jan 23 13:47:19.047 1995------------ 3-20 Known Problems, Restrictions, and Other Notes The help text for the DBS-E-FLOBCREATERR error incorrectly states that there is no applicable user action to recover from the problem. However, the reason for the failure displays in the next line below (not shown in this example). For example, the error may denote the "Permission denied" error. Therefore, to fix the problem in this situation, ensure that the directory specified by the LOCK_PATH argument is writeable from the 'dbsmgr' account. <> o You must call SQLSRV_CLOSE_CURSOR() before using COMMIT or ROLLBACK. Within SQL, executing a COMMIT or ROLLBACK statement implies that all open cursors are closed unless you are using the Oracle Rdb Hold cursors feature; this assumption is not true for Oracle SQL/Services. Oracle SQL/Services does not parse the SQL statements it passes so it does not know when a commit or roll back is executed. Instead, Oracle SQL/Services requires that the sqlsrv_close_cursor() call be issued to release the cursor-related data structures prior to a commit or roll back operation. To reuse the same cursor name, you must close that cursor before executing a COMMIT or ROLLBACK statement. o Oracle SQL/Services executors do not execute login.com procedures for clients. When a client connects to a server, the Oracle SQL/Services executor does not execute the login.com DCL command procedure located in the client user name's default directory. Therefore, client applications should not use logical names defined in login.com login procedures. Process logical names for Oracle SQL/Services executors can be defined only by a service's process initialization file. <> Known Problems, Restrictions, and Other Notes 3-21 3.1.5 Other Oracle SQL/Services Client Restrictions and Known Problems The following information describes additional Oracle SQL/Services client restrictions and known problems (where a restriction applies to only one platform, an icon denotes to which platform the restriction is applicable; when no platform specific icon is present, the restriction applies to all platforms): o Problem with SQL and Oracle SQL/Services error messages on Digital UNIX and Windows NT. On Digital UNIX and Windows NT (WIN32), when you use the printf statement to print out an error message, be careful. Error messages from Oracle SQL/Services or SQL usually start with: %SQLSRV... or %SQL... On Digital UNIX and Windows NT, a %S is a valid format type. If you have a message string such as: char *message = "%SQLSRV-F-ERROR, This is an error.\n"; And you use printf to print out the error message: printf (message); You may get garbage or a core dump because the printf statement interprets %S as a valid format in the message and expects you to pass in a pointer to a string. To avoid this problem, Oracle Corporation recommends that you use either a printf or puts statement when printing Oracle SQL/Services error messages: printf ("%s", message); or puts (message); <> o Use the node name for DECnet with the Windows NT client. 3-22 Known Problems, Restrictions, and Other Notes For the Windows NT client, if the transport is DECnet, the user should use the node name, not the DECnet address, for Oracle SQL/Services server node. <> o Avoid using cursor names starting with "SQLSRV_". In designing your applications, you should avoid using cursor names starting with the prefix "SQLSRV_"; this prefix is reserved and used by the Oracle SQL/Services product. o MS Windows client NetWare known restrictions. The following information describes known problems, restrictions, and provides additional information about the MS Windows Client NetWare Support for V6.0 and higher versions of Oracle SQL/Services. - The Token-Ring network topology is not supported. - Emulex Corporation's IP-Portal is not supported. <> o Nonblocking synchronous communications restrictions. The following Oracle SQL/Services restrictions relate to nonblocking synchronous communications (as specified in the sqsapiw.ini file): - Preliminary testing indicates varied success using nonblocking synchronous communications depending on how the calling application interacts with Oracle SQL/Services. To ensure correct operation, Oracle Corporation recommends use of blocking synchronous communications. Any use of the nonblocking synchronous communications feature is currently unsupported by Oracle Corporation. - Oracle SQL/Services does not support more than one ODBC driver or Oracle SQL/Services MS Windows client application running concurrently. - Oracle SQL/Services does not support concurrent processing of Oracle SQL/Services API calls. One API call must complete before another API call starts. Symptoms of this problem are the following: * MS Windows locks on the PC Known Problems, Restrictions, and Other Notes 3-23 * General protection fault * DECnet PATHWORKS error #32 EPIPEBroken pipe * Windows sockets Err #10036 WSAEINPROGRESS Operation in progress (#-2003) <> o Possible problems when multiple copies of sqsapiw.dll are in a PATH. Sites running the Oracle SQL/Services Windows client sqsapiw.dll should be alert to problems related to multiple versions of the DLL installed on the PC. Different versions of sqsapiw.dll can have different feature levels. Beginning with Oracle SQL/Services V5.1, sqsapiw.dll has an embedded version id to aid in identifying the version. Some software products, such as Oracle ODBC Driver for Rdb for the MS Windows operating system and DECquery, include sqsapiw.dll in the set of files installed. Some third-party ODBC-enabled application development products supply all Oracle ODBC Driver for Rdb for the MS Windows operating system files in their sets of files. Some of these products determine an exact location for installation. A single execution path on the PC might not be satisfactory for development and operation of all PC tools requiring sqsapiw.dll. Additionally, some versions of some debugging tools might not perform as expected when multiple versions of sqsapiw.dll are in the search path. <> o Oracle SQL/Services compatibility issue with the order of include files. With V4.1 and higher versions of Oracle SQL/Services, direct access to SQLDA and SQLCA structures is supported but is not recommended by Oracle Corporation. If direct access is used, the order of the Oracle SQL/Services include files must be as follows: 3-24 Known Problems, Restrictions, and Other Notes #include #include #include Compile errors will result if the include files are not in this order. o Allocating space for SQLSRV_VARCHAR and SQLSRV_VARBYTE data types can cause a problem. Be sure to specify the correct length for the SQLSRV_ VARCHAR and SQLSRV_VARBYTE data types in your API applications. Oracle SQL/Services does not issue an error message when the size of the data fields for SQLSRV_VARCHAR and SQLSRV_VARBYTE data types exceeds the size of the SQLLEN field in the SQLDA data structure. See the Guide to Using the Oracle SQL/Services Client API for information on allocating space for the SQLSRV_ VARBYTE data type and all other data types. 3.1.6 Oracle SQL/Services Software Installation Requirement and Compatibility Information The following information describes the Oracle SQL/Services hardware and software requirements and compatibility information for installing Oracle SQL/Services V7.0. Hardware Requirements Oracle SQL/Services server platforms require hardware configurations and Ethernet LAN connectivity supported by the prerequisite software listed in Software Requirements. Optional Hardware Oracle ODBC Driver for Rdb and Oracle SQL/Services client platforms require hardware configurations and Ethernet LAN connectivity supported by the prerequisite software listed in Software Requirements. Software Requirements The following software is required for the Oracle SQL/Services Digital UNIX server: o Digital UNIX Alpha Operating System, V3.2 or V4.0 o Oracle SQL/Services and Oracle Rdb for Digital UNIX Alpha - V7.0 Known Problems, Restrictions, and Other Notes 3-25 o One of the following network transport options: - TCP/IP transport - TCP/IP for the Digital UNIX Alpha, V3.2, bundled with the operating system - DECnet transport - DECnet/OSI, for Digital UNIX Alpha, V2.0 Table 3-1 lists the desktop clients and network transports supported by Oracle SQL/Services on the Digital UNIX platform. Table 3-1 Oracle SQL/Services on Digital UNIX Client __________/Network_Support_________________________________ Desktop________ _________Client_Transport_Support_________ Client_Platform__DECnet____TCP/IP____AppleTalk_SQL*Net_____ Oracle_ODBC_Driver_for_Rdb_Clients_________________________ Microsoft X X - X Windows Windows NT X86 X X - - Windows NT X X - - Alpha Microsoft X X - - Windows 95 ___________________________________________________________ Oracle_SQL/Services_Clients________________________________ Microsoft X X - X Windows Windows NT X86 X X - - Windows NT X X - - Alpha Microsoft X X - - Windows 95 Digital UNIX X X - X (continued on next page) 3-26 Known Problems, Restrictions, and Other Notes Table 3-1 (Cont.) Oracle SQL/Services on Digital UNIX __________________Client/Network_Support___________________ Desktop________ _________Client_Transport_Support_________ Client_Platform__DECnet____TCP/IP____AppleTalk_SQL*Net_____ Oracle_SQL/Services_Clients________________________________ Macintosh X X X[1] - Solaris - X - - [1]AppleTalk_is_not_available_from_a_Digital_UNIX_node_but_ is available from an OpenVMS node ___________________________________________________________ The following software is required for the Oracle SQL/Services OpenVMS Alpha server. o OpenVMS Alpha operating system V6.1 - V7.0 o Oracle SQL/Services and Oracle Rdb for OpenVMS Alpha V6.0 - V7.0 o One of the following network transport options: - DECnet transport - DECnet for OpenVMS Alpha, V6.1 - V7.0 - TCP/IP transport - DEC TCP/IP Services for OpenVMS Alpha, V3.3 or other DEC TCP/IP Services for OpenVMS compliant transport on the host system.[1] - Novell IPX/SPX transport - Emulex Leverage Host Services V3.1, File Sharing Services (FSS), V3.0. - AppleTalk - PATHWORKS for Macintosh, V1.3 - SQL*Net transport - Oracle SQL*Net Server, V2.1.5 ____________________ [1] DEC TCP/IP Services for OpenVMS Alpha V3.3 has been fully tested with Oracle SQL/Services. Other transports that comply with the DEC TCP/IP Services for the OpenVMS interface may function correctly but have not been fully tested by Oracle Corporation. Known Problems, Restrictions, and Other Notes 3-27 Table 3-2 lists the desktop clients and network transports supported by Oracle SQL/Services on the OpenVMS Alpha platform. Table 3-2 Oracle SQL/Services on OpenVMS Alpha Client __________/Network_Support_________________________________ Desktop________ _________Client_Transport_Support_________ IPX Client_Platform__DECnet__TCP/IP__/SPX____AppleTalSQL*Net___ Oracle_ODBC_Driver_for_Rdb_Clients_________________________ Microsoft X X X - X Windows Microsoft X X - - - Windows 95 Windows NT X86 X X - - - Windows NT X X - - - Alpha ___________________________________________________________ Oracle_SQL/Services_Clients________________________________ Microsoft X X X - X Windows Microsoft X X - - - Windows 95 Windows NT X86 X X - - - Windows NT X X - - - Alpha Digital UNIX X X - - X Macintosh X X - X - Solaris - X - - - OpenVMS VAX X X - - X OpenVMS_Alpha____X_______X_______-_______-_______X_________ The following software is required for the Oracle SQL/Services VAX servers. o OpenVMS VAX operating system, V5.5-2 - V7.0 3-28 Known Problems, Restrictions, and Other Notes o Oracle SQL/Services and Oracle Rdb for OpenVMS VAX - V6.0 - V7.0 o One of the following network transport options: - DECnet transport - DECnet for OpenVMS VAX, V5.5-2 - V7.0 - TCP/IP transport - DEC TCP/IP Services for OpenVMS VAX, V3.3 or other DEC TCP/IP Services for OpenVMS compliant transport on the host system.[1] - Novell IPX/SPX transport - Emulex Leverage Host Services V3.1, File Sharing Services (FSS), V3.0 - AppleTalk - PATHWORKS for Macintosh, V1.3 - SQL*Net transport - Oracle SQL*Net Server, V2.1.5 Table 3-3 lists the desktop clients and network transports supported by Oracle SQL/Services on the OpenVMS VAX platform. Table 3-3 Oracle SQL/Services on OpenVMS VAX Client/Network __________Support__________________________________________ Desktop________ _________Client_Transport_Support_________ IPX Client_Platform__DECnet__TCP/IP__/SPX____AppleTalSQL*Net___ Oracle_ODBC_Driver_for_Rdb_Clients_________________________ Microsoft X X X - X Windows Microsoft X X - - - Windows 95 Windows NT X86 X X - - - Windows NT X X - - - Alpha (continued on next page) Known Problems, Restrictions, and Other Notes 3-29 Table 3-3 (Cont.) Oracle SQL/Services on OpenVMS VAX Client __________________/Network_Support_________________________ Desktop________ _________Client_Transport_Support_________ IPX ___________________________________________________________ Oracle_SQL/Services_Clients________________________________ Microsoft X X X - X Windows Microsoft X X - - - Windows 95 Windows NT X86 X X - - - Windows NT X X - - - Alpha Digital UNIX X X - - X Macintosh X X - X - Solaris - X - - - OpenVMS VAX X X - - X OpenVMS_Alpha____X_______X_______-_______-_______X_________ Desktop Client Software Requirements This section describes the software required by each desktop client platform. Oracle ODBC Driver for Rdb Clients The following section describes the software required for each Oracle SQL/Services ODBC client and the supported transport. Oracle ODBC Driver for Rdb for the Windows NT X86 or Alpha Client (TCP/IP Transport): o Microsoft Windows NT operating system, V3.51 Oracle ODBC Driver for Rdb for the Windows NT X86 or Alpha Client (DECnet Transport): o Microsoft Windows NT operating system, V3.51 o PATHWORKS for Windows NT, V4.1B 3-30 Known Problems, Restrictions, and Other Notes Oracle ODBC Driver for Rdb for the MS Windows client (DECnet Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 o PATHWORKS V5.1 or V6.0 for DOS and Windows client software Oracle ODBC Driver for Rdb for the MS Windows client (TCP/IP Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 o One of the following network products: - PATHWORKS V5.1 or V6.0 for DOS and Windows client software - A Windows Sockets V1.1 specification compliant transport.[2] Oracle ODBC Driver for Rdb for the Microsoft Windows client (IPX/SPX Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 o Novell[R] NetWare 3.11 Windows Workstation Client with IPX.COM or IPXODI.COM, and NETX shell Oracle ODBC Driver for Rdb for the Microsoft Windows client (SQL*Net Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 o SQL*Net, Oracle SQL*Net on Microsoft Windows V2.2.2.0.3A or V2.3.2.1.0 o Oracle Network Manager V3.0.1.0.2A or V3.1.0.1.0 o Oracle Network Protocol Adapter o DECNet Transport - PATHWORKS V5.1, or V6.0 for DOS and Windows client software Known Problems, Restrictions, and Other Notes 3-31 o TCP/IP Transport - PATHWORKS V5.1, or V6.0 for DOS and Windows client software - A Windows Sockets V1.1 specification compliant transport. Oracle ODBC Driver for Rdb for the Windows 95 client (TCP/IP Transport): o Microsoft Windows 95 operating system, V4.00.950 Oracle ODBC Driver for Rdb for the Windows 95 client (DECnet Transport): o Microsoft Windows 95 operating system, V4.00.950 o PATHWORKS for DOS and Windows, Windows 95 V1.0A ________________________ Note ________________________ An additional patch is required to the PATHWORKS V1.0A kit. Call the Customer Support Center at Digital Equipment Corporation to obtain this patch. The Oracle ODBC Driver for Rdb will return the following error SQLSRV_DLL_ADDR_ERR (-2046). This means pwsock32.dll, a PATHWORKS dynamic link library, is missing a required routine. The name of the missing PATHWORKS routine is called SktEndNodeEnt. ______________________________________________________ Oracle SQL/Services Clients The following section describes the software required for each Oracle SQL/Services client and the supported transport. Oracle SQL/Services Windows NT X86 or Alpha Client (TCP /IP Transport): o Microsoft Windows NT operating system, V3.51 Oracle SQL/Services Windows NT X86 or Alpha Client (DECnet Transport): o Microsoft Windows NT operating system, V3.51 o PATHWORKS for Windows NT, V4.1B 3-32 Known Problems, Restrictions, and Other Notes Oracle SQL/Services Microsoft Windows client (DECnet Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 o PATHWORKS V5.1 or V6.0 for DOS and Windows client software Oracle SQL/Services Microsoft Windows client (TCP/IP Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 o One of the following network products: - PATHWORKS V5.1 or V6.0 for DOS and Windows client software - A Windows Sockets V1.1 specification compliant transport.[2] Oracle SQL/Services Microsoft Windows client (IPX/SPX Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 o Novell[R] NetWare 3.11 Windows Workstation Client with IPX.COM or IPXODI.COM, and NETX shell Oracle SQL/Services Microsoft Windows client (SQL*Net Transport): o MS-DOS operating system, V6.22 o Microsoft Windows, V3.1 ____________________ [2] PATHWORKS V5.1 or V6.0 for DOS and Windows client software and FTP[R] PC/TCP V2.3 have been fully tested with the Oracle SQL/Services and Oracle ODBC Driver for Rdb for the MS Windows clients. Other transports that comply with the Windows Sockets V1.1 specification may function correctly but have not been fully tested by Oracle Corporation. Known Problems, Restrictions, and Other Notes 3-33 o SQL*Net, Oracle SQL*Net on Microsoft Windows V2.2.2.0.3A or V2.3.2.1.0 o Oracle Network Manager V3.0.1.0.2A or 3.1.0.1.0 o Oracle Network Protocol Adapter o DECNet Transport - PATHWORKS V5.1, or V6.0 for DOS and Windows client software o TCP/IP Transport - PATHWORKS V5.1, or V6.0 for DOS and Windows client software - A Windows Sockets V1.1 specification compliant transport. Windows 95 client (TCP/IP Transport): o Microsoft Windows 95 operating system, V4.00.950 Windows 95 client (DECnet Transport): o Microsoft Windows 95 operating system, V4.00.950 o PATHWORKS for DOS and Windows, Windows 95 V1.0A Oracle SQL/Services Digital UNIX client (DECnet or TCP /IP Transports): o DEC OSF/1 Alpha (Digital UNIX) operating system, V3.2 or V4.0 o DECnet/OSI, V2.0, for Digital UNIX (required for DECnet applications only) Oracle SQL/Services Solaris client (TCP/IP Transport): o Solaris 2.4 environment Oracle SQL/Services Macintosh System 7.5.1 MPW client (DECnet, AppleTalk, or TCP/IP): o Macintosh operating system, V7.5.1 o PATHWORKS for Macintosh, V1.3 3-34 Known Problems, Restrictions, and Other Notes o AppleShare Workstation Software for System 7.5.1 (required for PATHWORKS installation) o MPW Development Environment, Version 3.3.1, and MPW, Version 3.3.1, C compiler (required for application development only) Oracle SQL/Services Macintosh System 7.5.1 ThinkC client (DECnet, AppleTalk, or TCP/IP): o Macintosh operating system, V7.5.1 o PATHWORKS for Macintosh, V1.3 o AppleShare Workstation Software for System 7.5.1 (required for PATHWORKS installation) o Symantec THINK C, V8 Release 4 C Compiler for the Macintosh system (required for application development only) 3.1.7 Oracle SQL/Services Documentation Errors or Omissions The following information describes Oracle SQL/Services documentation errors or omissions. o The Guide to Using the Oracle SQL/Services Client API does not describe changes to size and format of integer and floating-point data types Beginning with Oracle SQL/Services V5.1, the size and format of some integer and floating-point data types is changed as follows: - Trailing zeros occur in fixed-point numeric data types with SCALE FACTOR. Trailing zeros are now included after the decimal point up to the number of digits specified by the SCALE FACTOR. In versions of Oracle SQL/Services previous to V5.1, at most one trailing zero was included where the value was a whole number. The following examples illustrate the changes using a field defined as INTEGER(3): Known Problems, Restrictions, and Other Notes 3-35 V5.1 and Versions previous higher to V5.1 -------- ----------------- 1.000 1.0 23.400 23.4 567.890 567.89 - Trailing zeros occur in floating-point data types. Trailing zeros are now included in the fraction, and leading zeros are included in the exponent, up to the maximum precision available, for fields assigned the REAL and DOUBLE PRECISION data types. The following table illustrates the changes: Versions previous Data Type V5.1 and higher to V5.1 ---------------- ---------------------- ----------------- REAL 1.2340000E+01 1.234E+1 DOUBLE PRECISION 5.678900000000000E+001 5.6789E+1 - Size of TINYINT and REAL data types is changed. The maximum size of the TINYINT and REAL data types is changed to correctly reflect the precision of the respective data types. The following table shows the maximum lengths of the data types now and in previous versions: V5.1 and Versions previous Data type higher to V5.1 ---------- -------- ----------------- TINYINT 4 6 REAL 15 24 o The Guide to Using the Oracle SQL/Services Client API does not describe that the sqlsrv_associate() service returns SQL error code -1028 when connecting to a database service if the user has not been granted the right to attach to the database. When a user connects to a database service, the sqlsrv_ associate() service completes with the SQL error code -1028, SQL_NO_PRIV, if the user has been granted access to the Oracle SQL/Services service, but has not been granted the right to attach to the database. A record of the failure is written to the executor process's 3-36 Known Problems, Restrictions, and Other Notes log file. Note that the sqlsrv_associate() service completes with the Oracle SQL/Services error code -2034, SQLSRV_GETACCINF if the user has not been granted access to the Oracle SQL/Services service. Known Problems, Restrictions, and Other Notes 3-37