5
Deprecated and Desupported Features

Deprecated and Desupported Features

Many features are no longer advisable for use with Oracle8.

• Strings of Zero Length are not equivalent to a NULL
• The SELECT Privilege
• Date Format Strings are Stricter
• SERIALIZABLE=TRUE is no longer supported
• Non-Deferred Linking
• Single-Task Linking
• CONNECT INTERNAL
• Partition Views
• V6 Compatibility Behavior

Strings of Zero Length are not equivalent to a NULL

A string of zero length ('') is not equivalent to a NULL.

According to the ANSI SQL 1992 Transitional standard, a zero-length or empty string is not the same as NULL. The Oracle server may comply fully with this aspect of the standard in the future. Therefore, it is recommended that applications ensure that empty strings values and NULL are not treated equivalently.

The SELECT Privilege

The SELECT privilege will be required on tables that users update.

Always grant the SELECT privilege to a user or role if you grant the UPDATE or DELETE privileges on the table. See also Oracle8 Reference for more information about the initialization parameter, SQL92_SECURITY.

Date Format Strings are Stricter

In Oracle7, a space or punctuation character in the format string caused the corresponding character in the date string to be discarded. This caused incorrect dates to be entered into the database since alphanumeric characters were thrown out. In Oracle8, an error occurs if an alphanumeric character is found in the date string when a punctuation character or space is found in the format string.

Example:

TO_CHAR(TO_DATE('0297','MM/YY'), 'MM/YY')

Oracle7 result: 02/07

Oracle8 result: ORA-1861

SERIALIZABLE=TRUE is no longer supported

The initialization parameter SERIALIZABLE=TRUE is no longer supported in Oracle8 and beyond. The default behavior henceforth is as if SERIALIZABLE was set to FALSE. Use the SET TRANSACTION ISOLATION LEVEL SERIALIZABLE command to achieve similar transaction isolation behavior.

Non-Deferred Linking

Application developers are cautioned that Oracle plans to desupport non-deferred mode linking beginning with the release of Oracle9 (it will continue to be supported with all the releases of Oracle8). Recognizing these plans, application developers should no longer use non-deferred mode linking in developing new applications. Currently Oracle supports two linking modes:

1. Non-deferred linking: The Version 6 OCI (client) only supported non-deferred linking which meant that for each SQL statement, a parse, a bind and a define call were each executed separately with individual round trips between the client and the server. This significantly increased network traffic between the client and the server and reduced both the performance and scalability of OCI applications.

2. Deferred linking: Unlike the Version 6 OCI, the Version 7 OCI supports both non-deferred linking and deferred linking. Deferred mode linking essentially defers the bind and define steps until the statement executes, so it automatically bundles and defers the bind and define calls to execution time. Further, when the application is linked with deferred mode and a special parsing call is used (the OPARSE call with the DEFFLG set to a non-zero value), even the parse call can be deferred to execution time. Note that deferred mode linking does not depend on the specific OCI calls that the application uses, only on the link option that is selected.

Deferred mode linking therefore significantly reduces the number of round trips between the client and the server and as a result improves the performance and scalability of OCI applications. The default behavior of Version 7 OCI connected to the Oracle7 server is deferred mode linking. However, Version 7 OCI also supports non-deferred linking by setting specific link time options.

Further, Version 8 OCI has two types of calls: first, all the Version 7 OCI calls are supported with Version 8 OCI, i.e., they will work with a Version 8 OCI client by relinking the version 8 OCI libraries. Second, there are additional Version 8-specific OCI calls. The default mode with the first type of calls continues to be deferred mode linking; however, non-deferred mode linking is supported for these calls through all releases of Oracle8 by setting link time options. However, Version 8-specific calls use a different paradigm and as a result non-deferred mode linking is not necessary.

The various combinations of client side libraries and server with which non-deferred linking is currently supported are summarized below:

Table 5-1 Non-deferred Linking: Server and Client-side Libraries

Server		Client-side Libraries
	OCIv6	OCIv7	OCIv8(v7 calls)	OCIv8(v8 calls)	OCIv9
Oracle9	Not supported	Default: deferred Non-deferred supported	Default: deferred Non-deferred supported	Not supported	Not supported
Oracle8	Not supported	Default: deferred Non-deferred supported	Default: deferred Non-deferred supported	Not supported	Not supported
Oracle7	Non-deferred mode only	Default: deferred Non-deferred supported	Default: deferred Non-deferred supported	Not supported	Not supported
Oracle6	Non-deferred mode only	Default: deferred Non-deferred supported	Default: deferred Non-deferred supported	Not supported	Not supported

Oracle will continue to support deferred-mode linking with all the releases of Oracle8 (all 8.* releases). This has the following implications:

Applications Using Version 6 OCI Libraries

Since the Version 6 OCI library is not supported against the Oracle8 database, applications using the Version 6 library cannot be run against an Oracle8 database.

Applications Using Version 7 OCI Libraries

Applications using Version 7 OCI libraries can run in two configurations against an Oracle8 database:

• 1. They can be run with Version 7 OCI libraries against an Oracle8 database in non-deferred mode provided link time options are set appropriately.
• 2. They can also be relinked with the Version 8 OCI libraries and run in non-deferred mode provided link time options are set appropriately.

Oracle will support the first configuration through all the releases of Oracle8. However, the second configuration will not be supported in Oracle9. Therefore, applications that require non-deferred linking will not be able to upgrade to Oracle9 client-side libraries.

Applications using Version 8 OCI Libraries

Applications using Version 8 specific OCI calls, such as those used to access Oracle8's object types, do not need to use non-deferred mode linking since the Version 8 OCI uses a different paradigm. Applications using only Version 7 OCI calls will be able to use non-deferred mode linking but only through Oracle Release 8.1.

Single-Task Linking

Single-task linking is a feature used by a limited number of Oracle's customers primarily on the OpenVMS platform. Application developers are cautioned that Oracle will continue to support single-task linking with all the releases of Oracle8 (all 8.* releases) but will desupport it beginning with the first release after Oracle8.

With single-task linking, Oracle supports two configurations to link Oracle products and user-written applications against the Oracle database:

• 1. Single-task linking: In this case, applications are directly linked against the Oracle shareable image making single-task connection to Oracle.
• 2. Two-task linking: In this case, applications linked in a standalone configuration can only connect to Oracle using SQL*Net's two task drivers such as SQL*Net DECnet or SQL*Net VMS Mailbox on the OpenVMS platform. This is the typical configuration used in the large majority of client-server applications. With two task linking applications and tools connect with the Oracle7 database through a programmatic interface that creates a shadow process for each user process. This shadow process runs a copy of the Oracle shareable image on behalf of the user process using SQL*Net protocols to communicate between the user and shadow processes. Therefore, with this interface, user routines that invoke the Oracle7 server functions run as one process or task, and the Oracle7 routines that execute these functions run as the second task.

Oracle will continue to support single-task linking with all the releases of Oracle8 (all 8.* releases) but will desupport it beginning with the first release after Oracle8. Application developers who would like to use single-task linking to run their applications will not be able to do so against the first server release after Oracle8.

CONNECT INTERNAL

CONNECT INTERNAL is currently supported for backwards compatibility only. CONNECT INTERNAL will be completely desupported in the first maintenance release after Oracle8.1, so that CONNECT INTERNAL may no longer be used to connect to Oracle. If you have not done so already, you should plan to migrate your applications to use other connection syntax. See Oracle8 Administrator's Guide for further details.

Partition Views

In Oracle8, partitioned tables are strongly recommended in preference to partition views. If you must use partition views, please see "Rules and Guidelines for Use" in the Release 7.3.3 Tuning Guide on page 11-2.

V6 Compatibility Behavior

With Oracle7, Oracle offered a Version 6 [V6] Compatibility flag that allowed application developers developing Oracle7 applications to emulate Oracle6 behavior. With the release of Oracle8, users are cautioned that the Version 6 compatibility flag is being desupported effective immediately in all of the Oracle8 products including PL/SQL8, all the Oracle Precompilers, the Oracle8 Oracle Call Interface, SQL*Module, and SQL*Plus. The desupport of the V6 compatibility flag is consistent with Oracle's policy of supporting backwards compatibility and behavior from one version release upgrade to another, i.e., from Oracle6 to Oracle7 but not for more than one version release upgrade.

Users who do not absolutely need to maintain V6 behavior are encouraged to upgrade their Oracle7 clients to Oracle8. Users who absolutely need to continue to emulate V6 behavior for certain applications need to maintain one $ORACLE_HOME with an Oracle7 client for those applications. They can create a separate $ORACLE_HOME with an Oracle8 client for those applications for which they do not need V6 behavior.

Specifically, the V6 Compatibility flag emulated the following aspects of OracleV6 behavior with Oracle7:

• String literals are fixed length in Oracle7 but are treated as variable length with the V6 flag.
• PL/SQL Local char variables are fixed length in Oracle7 but are treated as variable length with the V6 flag.
• Return value of SQL Functions (e.g., USER) are fixed length characters in Oracle7 but are treated as variable length characters with the V6 flag.
• Select/Fetch of a NULL with no indicator raises an ORA-1405 error with Oracle7 but returns no error with the V6 flag.
• SQL group function is called at FETCH time with Oracle7 but is called at query execution time with the V6 flag.
• Describe of a fixed length string returns Type=96 with Oracle7 but returns Type=1 with the V6 flag.

All of the above are being desupported with the desupport of the V6 Compatibility Flag with Oracle8.

---