Understanding SQL*Net

**Coexistence of SQL*Net Version 1 and Version 2.x**

Note: SQL*Net version 1 cannot communicate with SQL*Net version 2, but it can coexist with it. Different releases of SQL*Net version 2 can communicate with each other. Therefore, the migration issues from version 1 to version 2, 2.1 or 2.2 are somewhat different from those from 2.0 to 2.1 or 2.2. In this section SQL*Net version 1 is contrasted with SQL*Net version 2.0, 2.1, or 2.2. In fact ,version 2 and later releases are similar in regard to migration issues from version 1.

If you already have a SQL*Net version 1 network, you must decide which of your nodes you will upgrade immediately to version 2.x, and which will continue to use only version 1.

Ideally, all platforms would run SQL*Net version 2.x supporting all protocols, and this section of the manual would not exist. In reality, there will be a period of time during which some platforms will have SQL*Net version 2.x available, and others will have SQL*Net version 1. During the transition, you may want to have some platforms with both SQL*Net version1 and SQL*Net version 2.x installed, so that they can communicate with all other platforms.

Note: SQL*Net version 1 nodes can communicate only with other SQL*Net version 1 nodes; however, version 2 and release 2.1 and 2.2 nodes can communicate with each other.

Version 1 Coexistence

In any SQL*Net installation, for each node there are three options directly related to the type of clients or servers with which each node communicates:

Only SQL*Net version 1 is installed. This installation assumes:

for a client, this node will connect only to servers running SQL*Net version 1

for a server, this node will receive connections only from clients running SQL*Net version 1

Only SQL*Net version 2.x is installed. This assumes:

for a client, this node will connect only to servers running SQL*Net version 2.x

for a server, this node will receive connections only from clients running SQL*Net version 2.x

Both SQL*Net version 2.x and SQL*Net version 1 are installed. (You do not need to reinstall SQL*Net version 1 if it is already installed.) This assumes:

for a client, this node will connect to multiple servers, some running SQL*Net version 1 and others running SQL*Net version 2.x. (This ability is not available on MS-DOS machines.)

for a server, this node will receive connections from clients running SQL*Net version 1 and SQL*Net version 2.x.

This model allows version 1 service to continue in your existing network until such time as all nodes are running version 2.x.

Distinguishing Version 1 and Version 2.x Connections

The version of SQL*Net that is used for a given connection is determined by the format of the connect string. Where a version 1 connect string is sent, the version 1 software and version 1 listener (on the server) are used. Where a TNS connect descriptor is sent, the version 2.x software and listener (on the server) are used.

Most of the time people use aliases for connect strings (in SQL*Net version 1) or service names for connect descriptors (in SQL*Net version 2.x). The way these aliases and service names are handled is operating system specific. On UNIX and VMS systems, if version 2.x is installed, the version 1 configuration files for mapping aliases to connect strings are not read. Therefore, to continue to use version 1 aliases, you must import them into the version 2.x network definition and generate the TNSNAMES.ORA configuration file. Network Manager makes this easy to do. See Chapter 5 in the Oracle Network Manager Administrator's Guide for further information. In general, personal computers will continue to read the version 1 configuration files to connect to the database indicated by the version 1 alias. See the Oracle operating system-specific documentation for your platform for details.

Note: If you are using Oracle Names, the TNSNAMES.ORA file is not necessary. Instead, the Names Servers read the destination addresses from the network definition database created by the Network Manager.