Oracle8 Migration
Release 8.0






Prev Next

Upgrading Version 7 Applications

This chapter provides information about using Oracle tools and applications with version 8. You do not need to modify existing (version 7) applications that do not use new version 8 features. Existing applications should achieve the same, or enhanced, functionality on a version 8 database.

The following topics are covered in this chapter:

Upgrading Oracle Applications to Version 8

The following version 8 features aid in the process of upgrading applications:

XA Calls: Incompatibility with Release 7.1 XA Calls

The version 8 database does not support version 7, release 7.1.6 XA calls, but it does support release 7.2 and 7.3 calls. Therefore, after migrating a version 7, release 7.1, database to version 8, relink associated Tuxedo applications (and any other associated applications that use XA calls) with the version 8 XA libraries.

Upgrading Precompiler and OCI Applications

Before you migrate your Oracle database from version 7 to version 8, upgrade any OCI and Precompiler applications that you plan to use with your version 8 databases. Then, you can test these applications on a sample version 8 database before migrating your production database.

The effort required to upgrade these applications depends on the degree to which you want to take advantage of the programmatic interfaces and version 8. In order of increasing difficulty, you can choose to:

The following sections, "Upgrading Precompiler Applications" and "Upgrading OCI Applications: Enabling Constraints", include the specific steps required to migrate Precompiler and OCI applications.

Upgrading Precompiler Applications

Complete the following steps to use your existing precompiler applications with a version 8 database:

  1. If you want to take advantage of the new features offered by version 8, an existing application may need to be recoded, or new applications written, to reflect the differences between version 7 and version 8. If you do not want to take advantage of version 8 features with an existing application, skip Step 1 and move on to Step 2.
  1. Relink the application with the version 8 runtime library, SQLLIB, which is included with the precompiler. This step is the only required step to use your applications with version 8.


    To run an existing pre-compiler application against a version 8 database, you do not need to re-precompile, nor recompile, the application.


Simplified Upgrading of Existing Applications

Applications written to work with version 7 precompilers, such as Pro*C 2.2 have a very smooth upgrade path to version 8 precompilers, such as Pro*C 3.0, due to extensive interoperability. Version 7 precompiler clients work with a version 8 server, and version 8 precompiler clients can work with a version 7 server. Specifically, the following list outlines precompiler/server compatibility:

The following three alternative upgrade paths are available for existing version 7 precompiler applications, without requiring recompilation or re-precompilation:

Migrating Ada Support in Version 8

The Pro*ADA product was officially de-supported by Oracle with version 7, release 7.3.

Migrate Pro*ADA to SQL*Module for Ada 8.0.3, which has a number of new features. However, SQL*Module for ADA 8.0.3 does not provide object support.

PL/SQL Backward Compatibility and Precompilers

PLSQL_V2_COMPATIBILITY backward compatibility behavior (see "PLSQL_V2_COMPATIBILITY Flag" on page 6-8) is available in the precompiler environment by setting the precompiler command line option, DBMS, as follows:

... DBMS=V7

Precompilers' Potential NCHAR/CHAR Migration or Compatibility Issues

NCHAR columns in version 7 are stored as CHAR. Their migration to version 8 requires special attention.

Upgrading OCI Applications: Enabling Constraints

OCI libraries are shipped with all version 8 releases. You can use existing version 7 OCI applications with a version 8 server, and you can ensure that constraints present in version 7 applications will be properly enabled when they are run on a version 8 database.

To ensure that constraints will be properly enabled requires that you relink the applications with the runtime OCI library for version 8, OCILIB, using one of the following version 8 deferred-mode settings:

OCI Application Link Line

For OCI applications, the version 8 link line differs from the version 7 link line. See the $ORACLE_HOME/rdbms/demo/ file for examples about using the version 8 link line as a version 8 OCI application is compiled.

Applications Using Version 6 OCI Libraries

The version 6 OCI library is not supported against the version 8 database. Therefore, applications that use the Oracle6 OCI library cannot be run against a version 8 database.

Upgrading LONGs to LOBs

Version 8 does not provide a facility for a direct migration of LONGs to LOBs. However, you can use the following indirect path for upgrading LONGs to LOBs:

  1. Write the data in the LONG RAW to a server side file.
  1. Use the version 8 command CREATE DIRECTORY to point to the directory where the file resides.
  2. Use the version 8 command OCILobLoadFromFile or DBMS_LOB.LOADFROMFILE to populate the BLOB with the data in the file.

If the LONG RAW is not too big, you also can read the LONG RAW into a buffer and call OCILobWrite or DBMS_LOB.WRITE to write the LONG RAW data to the BLOB.

Upgrading Version 7 Forms or Developer/2000 Applications

Forms applications run the same on version 7 and version 8. However, review the new features described in Getting to Know Oracle8 and the Oracle8 Enterprise Edition to determine whether any of the new version 8 features would be beneficial to your applications or might otherwise affect them. Information about the ways in which the version 8 features interact with Forms applications is provided in the Oracle Forms 4.5 Reference Manual, Vol.1 and Vol. 2, the Oracle Forms 4.5 Developer's Guide and Forms 4.5 Advanced Techniques.

Data Dictionary Views Update

Certain data dictionary views maintained in version 7 for backward compatibility to Oracle Version 5 and Version 6, created in the files CATALOG5.SQL and CATALOG6.SQL, are obsolete with version 8. Remove all references to these data dictionary views from your database tools and applications.

Upgrading SQL*Plus Scripts

To use SQL*Plus release 4.0, version 8, and PL/SQL Version 3 functionality, complete the following steps:

PL/SQL V2 Compatibility Mode

A PL/SQL V2 compatibility mode is available in PL/SQL V8.0.3. This mode is enabled by the PLSQL_V2_COMPATIBILITY flag.

You can set this flag in any one of the following three ways:


The PLSQL_V2_COMPATIBILITY flag provides compatibility between PL/SQL V8.03 and PL/SQL V2 in the following situations:

This syntax is incorrect and should be changed to the following:

return variable-type

The PL/SQL V8.0.3 compiler issues an error when it encounters the illegal syntax. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves the same as PL/SQL V2 and does not issues an error.

This use of an IN parameter is incorrect. PL/SQL V8.0.3 correctly enforces the read-only semantics of IN parameters and does not let index table methods modify index tables passed in as IN parameters. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves the same as PL/SQL V2 and allows the parameter.

Keyword Behavior Differences: Version 7 vs. Version 8

The following keywords or types included in both version 7 and version 8 produce slightly different error message identifiers when used as a function name in a SELECT list:

Keyword   Version 8 Behavior   Version 7 Behavior  


Generates errors: ORA-06550 and PLS-00222  

Generates errors: ORA-06552 and PLS-222  

New Keywords or Types Behavior Differences: Version 7 vs. Version 8

The following words are newly defined in version 8 as keywords or types:













In version 8, each may be used as a function name in a SELECT list, however, if it is qualified with a schema, as schema.function, as in the following example:

select scott.true() ...

In version 8, if a schema qualification is missing, these words generate an error, while, in version 7, their unqualified use functions without error.

SQL*Net or Net8

Version 7 and version 8 releases can use SQL*Net, Version 2 or Net8; SQL*Net V1, however, used a different network addressing scheme and cannot be used with version 8. Therefore, the following requirements apply to migrated applications:

Upgrading SQL*Net V1 to SQL*Net V2

Make the following changes to upgrade from SQL*Net V1 to V2:

For complete instructions about upgrading SQL*Net from Version 1 to Version 2, refer to SQL*Net V2.0 Administrator's Guide and SQL*Net Version 2 Migration Guide.

Version 7 Net2 Clients and Connection Manager

Existing version 7 OCI-Net2 clients can use the connection manager without relinking. The only requirement is that the client's connect string must go through the CMAN.

Thin-client JDBC is the same as a version 7-Net2 client, as are all current clients that do not relink.

Other version 8 benefits also are available to existing clients without relinking, including database link concentration, reduced SQL statement memory, reduced overall shared pool consumption, serially reusable SQL for SQL and PL/SQL, scalable cursor authorization, PL/SQL constant pool paging, more efficient SQL*Plus-PL/SQL interaction, improved parse concurrency, faster array inserts, faster table scans, bulk SQL from PL/SQL, faster character set conversion, and faster multibyte processing.

Net8 Features Available to Relinked Version 7 Clients

Version 7 OCI/UPI clients who relink with Net8 can use connection pooling and OSS authentication. No code changes are necessary to gain this functionality. The same applies to precompilers and application tools that you relink.

Version 8 Net8 Clients

Applications that are recoded to use version 8 OCI can implement all version 8 features, including the following:

Version 7 clients also can make selective use of version 8 OCI, mixing version 7 and version 8 calls. The degree of functionality added depends on which calls are used. Utility program such as SQL*Loader and Export/Import convert a subset of calls, primarily for object table access. The encryption API and password reset calls are independently usable as well. To enable failover, prefetch, piggyback commit/cancel, or client-side conversions, use version 8 OCI for all phases of the statements being processed.

Backup Management: EBU and Recovery Manager

EBU and Recovery Manager are client-side utilities for managing Oracle database backups. However, for managing version 8 database backups, you must use Recovery Manager. You cannot use EBU with version 8.

Both EBU and Recovery Manager use the Media Management Language (MML) to talk to third party storage subsystems, such as Legato or EMC.

Investments in tape subsystem management modules for EBU and version 7 should be reusable under Recovery Manager and version 8. However, backup volume formats are not reusable. You need to write new backups to the storage subsystem under version 8 because Recovery Manager produces a different format, and backups from version 7 generally are not useful for version 8 restores.


The scripting language for Recovery Manager is completely different from the scripting language for EBU.


Dictionary Protection

Using tablespace-relative data block addresses (DBAs) would be expected to cause problems in any applications that:

Creating and accessing user tables in SYS schema is not secure. Therefore, applications are expected to move the objects to a different schema. Use the O7_DICTIONARY_ACCESSIBILITY switch for temporary compatibility, but this switch is only for interim use.

Applications should not attempt to connect to user SYS without the SYSDBA option. Instead of connecting to the user SYS and sharing the password, grant SYSDBA privilege to the normal user, who will connect to the database as SYSDBA to connect to SYS schema. Refer to Oracle7 Server Administrator's Guide for details about the SYSDBA privilege.

In some cases, the user with `ANY' privilege uses the DML on the dictionary. For example, the user with DELETE ANY TABLE uses the delete statement to purge the audit records in the aud$ table. In such cases, the users can grant the privileges on the objects to the users to do the specific task.

Ideally, a migration script will be available for updating the password column of the user SYS in the dictionary to NULL.

Password Management

Make the following changes to a version 7 (or earlier) application to enable it to work with version 8 password management:

If you do not make these changes to version 7 applications, one of the Oracle tools, such as SQL*Plus or SQL Server Manager, will be required to allow the password change after a user's account expires.

However, this version 8 password management feature is off by default. If a version 8 server system does not implement the password-expiration feature, no change is required to version 7 clients for password management. The DEFAULT profile sets all the parameters to UNLIMITED, and sets the password complexity check routine to NULL.

The password verification routine is exported/imported along with its profile definition. The user's history table can also be imported/exported in version 8, release 8.0.2 and higher.

Version 7 or Lower Client with Version 8 Server

Version 7 clients use version 7 OCI calls to connect to the server; therefore, version 8 password expiration cannot be detected. However, other features of version 8 password management, work for version 7 clients. Full version 8 password management, including password expiration handling, can operate in version 7 clients after you make the minor change of replacing their version 7 logon call with the version 8 logon call.

Version 8 Client with Version 7 or Lower Server

A version 8 client can be coded to work with version 7 or lower servers. An example of the code for such version 8 clients follows:

OCISessionBegin(...) /* call v8 logon OCI call */
{ /* Check for password expiration and take appropriate action*/

Export/Import Usage, Partitioned Objects

The version 8 export dump file format differs from the version 7 format. Consequently, dump files that have been generated by version 8 Export cannot be imported by version 7 Import into version 7 databases. However, the version 7 version of Export can be used, after running the CATEXP7.SQL script, to export a version 8 database to version 7. Partitioned tables are not exported by the version 7 version of Export. If you need to move a partitioned table to a version 7 database, it first must be reorganized into a non-partitioned table.

Migration and Compatibility Issues for Thread Safety, OCI

The ORLON and OLON calls are not supported in version 8. However, you still should use OLOG, even for single-threaded applications.


The OLOG call is required for multi-threaded applications.


See Also:

Oracle Call Interface Programmer's Guide for more information about Thread Safety and OCI.


Upgrade and Compatibility Issues for Standby Database

Standby Database operates only on version 7, release 7.3 or version 8. The primary and standby databases must be running the same version and release number of Oracle server, and they must be running on the same release of the operating system platform.

See Also:

Your platform-specific Oracle documentation.


To use Standby Database correctly, consider the following:

To migrate the Standby Database to version 8, perform the following steps:

  1. Apply all redo logs created under version 7.
  1. Make sure the primary database has been opened successfully under version 8.
  2. Install version 8 software at the standby site.
  3. Copy the version 8 control file and Datafile 1 to the standby site.
  4. Make a new control file for the standby database from the primary database.

    See Also:

    Oracle8 SQL Reference, theOracle8 Administrator's Guide, and Oracle8 Parallel Server Concepts and Administration for more information about Standby Database.


Compatibility Issues for Export/Import

Direct Path Export uses an encoding format that is different from the encoding format used by Conventional Path Export. Therefore, the dump files generated by Direct Path Export and Conventional Path Export are different.

The version 8 Import Utility can use dump files generated by either Direct Path Export or Conventional Path Export.

Pre-version 8 dump files are upward compatible with the version 8 Import Utility. Dump file data produced by current or prior versions/releases of Direct Path Export or by Conventional Path Export alike have the same upward compatibility with future Oracle server versions and releases.

Downward Compatibility Techniques and Limitations

The version 8 Export Utility makes dump files that are not downward compatible with pre-version 8 Import utilities. Their exported data cannot be imported by pre-version 8 Import utilities.

To export version 8 data to a version 7 (or earlier) database, the version 7 version of Export must be used, after the CATEXP7.SQL script has been run.


In version 8, the DBA can declare the use of the national character set (NCHAR) for specific columns, attributes, PL/SQL variables, parameters, and return results. Unless such an explicit declaration is made, use of NCHAR and NLS is, for the most part, invisible and has no effect on other version 8 features. An exception is that SELECT statements on the props$ or VALUE$ dictionary view may return the CHARACTER_SET_NAME column or the NLS_NCHAR_CHARACTERSET row.

Migration and NCHAR and NLS

The props$ dictionary table contains two rows that describe the character set(s) specified in the CREATE DATABASE statement. The row holding NAME='NLS_CHARACTERSET' has the database character set's name in VALUE$. The row holding NAME='NLS_NCHAR_CHARACTER SET' has the national character set's name in VALUE$.

NLS_DATABASE_PARAMETERS contains a new row that holds the NCHAR character set name specified in the CREATE DATABASE statement. There is a new parameter, NLS_NCHAR_CHARACTERSET.

Compared to release 7.3, various views contain the new column, CHARACTER_SET_NAME, whose value is:

              1, `CHAR_CS',
              2, `NCHAR_CS',

where x$ represents one of the base tables. The DATA_TYPE or COLTYPE column value of the view will not change to indicate the character set choice.

NCHAR and NLS Compatibility and Interoperability

A release 7.1 and higher clients can interact with a version 8 server that holds data in the national character set. If the output national character data pass through a bind or define handle, the OCI handles the conversion to the client's database character set invisibly. If the data is needed as an input bind value, and is used where only a national character set string is allowed, the SQL or PL/SQL code using the value should surround the use of the bind variable, which will be perceived as having the database character set, with a call to CSCONVERT() to convert it to the national character set. The client is restricted in this case to passing the data in the client's database character set, which may not have the complete repertoire of the national character set.

A version 6 or version 7 client can RPC to a subprogram with ANY_CS parameters, which will interpret their actual argument as having the server's database character set. A version 6 or version 7 client cannot RPC to a subprogram with a parameter declared as using the national character set, and cannot RPC to a function with a return result using the national character set. These disallowed cases will be caught at run-time, not at compile-time.

A version 6 or version 7 client using SQL code embedded in PL/SQL cannot use the CSCONVERT() function, or CHR() with a second argument, directly in the SQL statement because these do not exist in a version 6 or version 7 client's PL/SQL package STANDARD. The following two stored procedures can be created on the server to deal with this:

create function to_nchar_cs(t varchar2) return nchar varying
      is begin
            return csconvert(t, nchar_cs);
      create function to_char_cs(t nchar varying) return varchar2
      is begin
            return csconvert(t, char_cs);


Copyright © 1997 Oracle Corporation.

All Rights Reserved.