Oracle8 Migration Release 8.0 A58243-01 |
Library | Product | Contents | Index

# 6
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
- Upgrading Precompiler and OCI Applications
- Upgrading LONGs to LOBs
- Upgrading Version 7 Forms or Developer/2000 Applications
- Data Dictionary Views Update
- Upgrading SQL*Plus Scripts
- PL/SQL V2 Compatibility Mode
- SQL*Net or Net8
- Backup Management: EBU and Recovery Manager
- Dictionary Protection
- Password Management
- Export/Import Usage, Partitioned Objects
- Migration and Compatibility Issues for Thread Safety, OCI
- Upgrade and Compatibility Issues for Standby Database
- Compatibility Issues for Export/Import
- NCHAR and NLS Use

## Upgrading Oracle Applications to Version 8

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

- Both SQL*Net V.2 and Net8 work with various Oracle versions and releases. Thus, version 7 and version 8 databases can communicate by using SQL*Net V2 and Net8.

  Note: SQL*Net V1, however, used a different network addressing scheme and cannot be used with version 8.

- For application creation and management, the programming interface (such as the Oracle precompilers and Oracle Call Interface or OCI) remains unchanged between different versions of Oracle. For example, you can use SQL*Net or Net8, or you can relink applications designed for an earlier release database to run them with a version 8 release, or with version 7.
- Backward compatibility generally is built in to accommodate small incompatibilities between different Oracle releases.
- Many new features and enhancements are automatically available after migration. Some of these new features may provide improved performance.

### 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:

- maintain your existing performance and functionality
- boost the performance of your applications
- take advantage of the new version 8 database functionality

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.

   Note: 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:

- Applications using version 7 Pro*C 2.2 work unchanged against a version 8 server (all SQLLIB function calls work against version 8 servers).
- Applications using version 8 Pro*C 3.0 can work against a version 7 server if they do not use any object capabilities of the precompiler or server.
- Version 7 and version 8 SQLLIB functions can be mixed in the same application and the same transaction.

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

- Retain version 7 client application without any modification.
  It will continue to work against a new version 8 server.
- Upgrade to version 8 client but do not modify the application. To upgrade a version 7 client to a version 8 client, you only need to relink the new version of OCILIB. Relinked version 7 OCI applications work unchanged against a version 8 server.
- Upgrade to version 8 and modify the application to leverage new version 8 precompiler capabilities for performance and scalability benefits, or to use any object capabilities of the version 8 server. Existing (version 7) applications must be recoded using the new version 8 SQLLIB calls, and must be relinked with the new SQLLIB, to run against a version 8 server. This path is required for any application to use any object capability of the version 8 server.

#### 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:

- Non-deferred mode, to maintain existing (version 7) performance levels
- Deferred mode linking, to improve performance of applications

  Note: With deferred linking, bind and define errors may not be reported to the application immediately after bind and define operations. Instead, these errors may be reported later, at the time of a DESCRIBE, EXECUTE, or FETCH call.

  See Also: Oracle Call Interface Programmer's Guide for more information.

### 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/demo_rdbms.mk 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:

- Make the following changes to SQL*Plus 3.x scripts to convert them into SQL*Plus 4.0 scripts:
  - If a script contains the line SET COMPATIBILITY V7, change it to SET COMPATIBILITY V8, or remove the line so that the default version 8 setting is used.
  - Check any LOGIN.SQL file(s) and change any SET COMPATIBILITY V7 line found to SET COMPATIBILITY V8.
  - Refer to the SQL*Plus User's Guide and Reference to learn about new functionality in SQL*Plus release 4.0.
- To use new version 8 functionality, change existing SQL scripts to conform to version 8 syntax. Existing SQL scripts run unchanged on version 8, and require no modification, if they do not use new version 8 functionality

  See Also: Oracle8 SQL Reference for more information about upgrading SQL scripts.

  Note: No changes to PL/SQL procedures are required.

  .

## 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:

- Add the following line to the INIT.ORA file:

      PLSQL_V2_COMPATIBILITY=TRUE

- Issue the following command:

      ALTER SYSTEM SET PLSQL_V2_COMPATIBILITY = TRUE;

- Issue the following command:

      ALTER SESSION SET PLSQL_V2_COMPATIBILITY = TRUE;

### PLSQL_V2_COMPATIBILITY Flag

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

- The PL/SQL V2 compiler allows a record type or index table type to be referenced before its definition in the source. PL/SQL V8.0.3 strictly requires that the type definition precede reference to the type in the source. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves the same as PL/SQL V2 in regard to type definitions.
- The PL/SQL V2 compiler allows the following illegal syntax:

      return variable-expression

  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.

- In PL/SQL V2 it is possible to modify/delete elements of an index table passed in as an IN parameter, as in the following example:

      function foo (x IN table_t) is
      begin
      x.delete(2);
      end;

  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.

- PL/SQL V2 allows the passing (as an OUT parameter) of fields of IN parameters that are records, but PL/SQL V8.0.3 does not allow this type of passing. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves the same as PL/SQL V2 and allows this type of passing.
- The PL/SQL V2 compiler permits fields of OUT parameters that are record variables to be used in expression contexts (for example, in a dot-qualified name on the right-hand side of an assignment statement).

  This use of OUT parameters should not be permitted. PL/SQL V8.0.3 does not permit OUT parameters to be used in expression contexts. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves the same as PL/SQL V2 in this regard.

- PL/SQL V2 allows OUT parameters in the FROM clause of a SELECT
  list. PL/SQL V8.0.3 does not allow this use of OUT parameters. However, when you enable PL/SQL V2 compatibility mode, PL/SQL V8.0.3 behaves
  the same the PL/SQL V2 in this regard.

### 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
--- | --- | ---
CHARACTER, COMMIT, DEC, FALSE, INT, NUMERIC, REAL, SAVEPOINT, TRUE | 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:

BFILE | CLOB | NCLOB | SYS_OP_NTCIMG
BLOB | DEREF | NVARCHAR2 | VALUE
CAST | NCHAR | REF |

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:

- Both the client and server must run SQL*Net, Version 2 or Net8.
- The Multi-Threaded Server requires SQL*Net, Version 2 or Net8 on the server. Therefore, to connect using the Multi-Threaded Server, you also must use SQL*Net, Version 2 or Net8 on the client.

### Upgrading SQL*Net V1 to SQL*Net V2

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

- Install SQL*Net, Version 2 or Net8.
- Re-create each connect string as the next version's connect descriptor. SQL*Net Version 2 uses the syntax outlined in the SQL*Net V2.0 Administrator's Guide or Oracle Net8 Administrator's Guide.
- Relink any precompiler programs and Oracle executables that you want to use with SQL*Net Version 2, including SQLplus and SQLforms.

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:

- application failover
- transparent data prefetch
- piggybacked commit and cancel, which reduces network roundtrips and server footprint
- full dynamic statement execution in one roundtrip (as in SQL*Plus `select * from emp`)
- faster login, which eliminates 3 roundtrips when NLS_LANG is set
- new object table API, object cache
- security toolkit API (encryption, signatures)
- warnings (including password expiration, failover)
- server scalability due to client-side type conversion
- NCHAR
- LOB
- longer CHAR/VARCHAR
- DML returning values
- separation of server, user, and transaction handles, for simplifying middle-tier implementations

  Note: The only client program fully converted to version 8 OCI is SQL*Plus.

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.

Note: 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:

- create user tables in the SYS schema, and
- access them using the `ANY' privileges.

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:

- Use the version 8 OCI call, OCISessionBegin(), to connect to the server. If the server returns SUCCESS_WITH_INFO, check to see if this is a password expiration error. If the password has expired but is still within the grace period, signal a warning to the user and use OCIChangePassword() call to change the user's password (the password change call is optional but recommended).
- If the password has expired and the error is returned, use the version 8 OCI call, OCIChangePassword(), to change the user's password.

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 */
    if (SUCCESS_WITH_INFO) then
    { /* Check for password expiration and take appropriate action*/
    ...
    OCIChangePassword(...);
    ...
    }

## 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.

Note: 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:

- The data files, log files, and control files of the primary and standby databases must exist separately on separate physical media. A single control file cannot serve both the primary and standby databases.
- Although not required, it is good administrative procedure to make the following features the same on the primary and standby databases:
  - database identification string
  - data files names
  - log files names
  - control files names

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.

## NCHAR and NLS Use

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:

    DECODE(x$.CHARSETFORM,
                  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);
          end;
          create function to_char_cs(t nchar varying) return varchar2
          is begin
                return csconvert(t, char_cs);
          end;

Prev | Next
| Copyright © 1997 Oracle Corporation. All Rights Reserved. |
Library | Product | Contents | Index