From Ingres Community Wiki

Contents 1 Ingres ODBC Driver Names on Multiple Ingres Installations 1.1 Problems with the current ODBC Driver Naming Scheme 1.2 Proposal for Reducing Driver Name Ambiguity 1.3 Limitations 1.4 Platform Considerations 1.5 Affected Components 1.6 Documentation Changes 2 References 3 Notes 3.1 Ingres Enhancement Number 3.2 DDS Review Summary 3.3 Test Considerations 4 Documentation 4.1 Release Summary 4.2 Connectivity Guide

Ingres ODBC Driver Names on Multiple Ingres Installations

Unlike the Ingres JDBC or Ingres .Net driver, the Ingres ODBC Driver depends on the Ingres environment with which the ODBC driver is installed. This presents no problem if the installation target includes only one version of Ingres. However, problems may arise if the target platform has more than one Ingres installation. A key part of ODBC installation is the driver name, which is associated with a particular driver and installation path. The driver name is referenced in connection strings and as an ODBC DSN configuration attribute. If the platform has multiple Ingres installations, there may be confusion as to what driver is referenced by a particular driver name. In some instances, the driver installation may be corrupted by the current ODBC driver naming scheme.

Problems with the current ODBC Driver Naming Scheme

To address the multiple installation problem, ODBC installers rely on a simplistic naming convention. The installer always installs the latest driver as "Ingres", plus a driver name associated with the driver version. Thus, an Ingres 9.1 installation installs the driver as "Ingres" and "Ingres 9.1", with both driver names resolving to the current definition of %II_SYSTEM%\ingres\bin\caiiod35.dll. Here is an example of the confusion that results if the platform has two 9.1 installations:

1. A customer installs a production version of Ingres 9.1.0 into one location with installation code II. The driver names are "Ingres" and "Ingres 9.1". The customer's ODBC application references "Ingres 9.1" as the driver name in the connection string.
2. The customer installs Ingres 9.1.2 into a test area with installation code JJ. The driver names are also "Ingres" and "Ingres 9.1", but now the "Ingres 9.1" driver name points at the JJ installation.
3. The II installation now loads the JJ driver when connecting, which may result in different driver behavior or even a failure to load the driver.

There are many variations of this problem. Documentation of the behavior is as confusing as the problem itself.

Proposal for Reducing Driver Name Ambiguity

Ingres installations are also named, but use a naming convention that is independent of the II_INSTALLATION path. Instead, the installation name is associated with the installation code. Thus, if a customer installs an Ingres II installation, uninstalls it, and re-installs Ingres to a different installation path, everything dependent on II points at the new path. The ODBC naming convention will follow the lead of Ingres. Instead of installing the drivers as "Ingres" and "Ingres 9.1", the driver will be installed as "Ingres" and "Ingres II". So, following the example above, the following would happen if this proposal were retrofitted to Ingres 9.1:

1. The 9.1.0 driver is installed into the II installation as "Ingres" and "Ingres II". The customer application references "Ingres II" in the connection string.
2. The 9.1.2 driver is installed into the JJ installation as "Ingres" and "Ingres JJ".
3. The II installation still loads the II driver, even if the II installation is uninstalled and re-installed in a different location.

Use of the installation code, rather than the Ingres version, to identify Ingres ODBC drivers, allows any number of Ingres installations to include ODBC driver names specific to the installation. If a customer upgrades Ingres to a new release of Ingres within the same installation path, the ODBC driver names are unaffected and require no modifications to ODBC configuration or ODBC connection strings.

Customers upgrading from an earlier version of Ingres might find themselves saddled with three or more driver names. The following examples would be typical:

1. The 9.1.0 driver is installed into the II installation as "Ingres" and "Ingres 9.1".
2. The customer upgrades the II installation to Ingres 10.0 without uninstalling Ingres 9.1. Now there are three driver names, "Ingres", "Ingres 9.1", and "Ingres II", now pointing at the same driver.

1. The 9.1.0 driver is installed into the II installation as "Ingres" and "Ingres 9.1".
2. The customer upgrades the II installation to Ingres 10.0 into a different location. Now there are three driver names, "Ingres", "Ingres 9.1", and "Ingres II", bug "Ingres 9.1" points at the 9.1 driver, and "Ingres" and "Ingres II" point at the new driver.

One could remove the driver using the Windows ODBC installer API, but there are limitations to the installer API. One cannot simply remove the driver definition, otherwise existing DSN defintions point at the driver will be broken. The Windows API has a option to remove the ODBC DSN definitions, but the customer may misunderstand if selecting this option and lose all of his or her DSN definitions without intending to do so. For this reason, the ODBC patch installer has avoided the option of removing a driver defintion.

In both cases, if the documentation is explicit that ODBC applications should use the driver name "Ingres II" for all future ODBC applications, confusion can be avoided.

Prior Ingres releases will continue to support the prior driver naming convention.

Limitations

Here are some some known limitations to this proposal:

• The driver name "Ingres" will continue to be ambivalent, and will point to that path of whatever version of Ingres was last installed. This will be maintained for backward compatibility.
• The Windows ODBC Administrator defines the Driver attribute as a hard-coded path. Thus, if DSN definitions are created for Ingres II, and Ingres II is uninstalled and re-installed in a different path, the driver defined by the ODBC DSN will fail to load. The only remedy is to delete the DSN definition and re-create it.

Platform Considerations

The ODBC CLI is unaffected by this proposal. The CLI simply loads the driver from $II_SYSTEM/ingres/lib.

UnixODBC configuration files may use either driver names or hard-coded paths for the Driver attribute of the ODBC DSN configuration file. The Ingres ODBC administrator, which is compatible with unixODBC environments, uses driver names for the Driver attribute, and thus benefits from this proposal. If the unixODBC configuration file is generated another way, and uses hard-coded driver paths, the same limitations apply as in the Windows environment: the DSN will have to be edited so that the Driver attribute points at the new driver location, if applicable.

Affected Components

• The Ingres Windows installer
• The Ingres ODBC configuration API, including the iiodbcinst, iisuodbc and iiodbcadmin utilities.
• The Ingres ODBC patch installer

Documentation Changes

The ODBC patch installer's help page will require documentation. There is a section in the Connectivity Guide called "Support for Previously Released ODBC Drivers" that will require modification.

References

Notes

Ingres Enhancement Number

SIR 123641.

DDS Review Summary

Test Considerations

Documentation

Release Summary

ODBC Driver Names

The Ingres instance ID, rather than the Ingres version, is now used to identify Ingres ODBC drivers. The Ingres ODBC driver is installed with the driver names "Ingres" and "Ingres xx," where "xx" is the value of II_INSTALLATION.

This feature allows any number of Ingres instances to include ODBC driver names specific to the instance. If you upgrade to a new release of Ingres in the same installation path, the ODBC driver names are unaffected and require no modifications to ODBC configuration or ODBC connection strings. For more information, see ODBC Driver Names in the chapter "Understanding ODBC Connectivity" in the Connectivity Guide.

Connectivity Guide

The Ingres Connectivity Guide for Ingres 10, chapter "Understanding ODBC Connectivity" will also be updated.

ODBC Driver Names

The Ingres ODBC driver is installed with the driver names “Ingres” and “Ingres xx", where xx is the value of II_INSTALLATION. Thus, the driver name “Ingres” will always reference the most recent installation of the Ingres ODBC driver, and "Ingres xx" is the name of the driver associated with an Ingres installation with an instance ID of "xx", regardless of the Ingres version or location. Read-only drivers are named "Ingres Read Only" and "Ingres xx Read Only."

If multiple versions of Ingres are installed on the same machine, we recommend to always reference the "Ingres xx" driver in connection strings or when creating an ODBC data source name; otherwise, subsequent installations or upgrades may corrupt the driver path defined by the driver name "Ingres". If the machine has only one Ingres installation, "Ingres" or "Ingres xx" can be used.