How You Plan for Application Issues

To ensure your applications can be tested in the new installation, do the following:

• Before starting the upgrade, take an application and database inventory. You must have the complete and current source code for all applications. If the source code does not match what users are running, problems can result.
• Make sure that each application can be rebuilt from the source code because you will eventually recompile your applications under the new version.
• If an application cannot be rebuilt, test the original executable under Ingres as soon as possible. If the application has no upward compatibility issues (for example, reserved words), it may be possible to run the old application against an Ingres installation and database. Otherwise, you will have to recreate the application or do without it.
• Try to synchronize the test and live Ingres upgrades with an appropriate time in the application life cycle.

  If application development is underway, plan how to coordinate new development with Ingres compatibility. Upgrades from newer versions (OpenIngres 1.2 or newer) may be able to move quickly enough to avoid the issue. Preparing an upgrade from Ingres 6.4 can take long enough to rule out a full stop in development.

  One site, for example, addressed the timing issue by synchronizing Ingres compatibility with a code release. Then, the development installation was converted to Ingres, while an Ingres 6.4 "bug fix" installation was maintained on a different machine.

The Test Plan for Applications

You must test your applications with the new version of Ingres before performing a production upgrade. The cost of testing every function in every application can be prohibitive, but fortunately, such testing is rarely necessary. A proper test plan can reduce testing time to a week or two.

A successful test plan uses the following process:

1. Rank the importance of each function in each application.
2. Test only the most important functions of each application.
3. Fix problems found after the upgrade as quickly as possible.

Categories of Application Functions

When determining the importance of an application function, ask "How long can we live without this function?" One successful testing approach divides application functions into three categories, as follows:

• Functions that are business critical, and must be operational immediately after the upgrade. No delay is permitted. Examples may include customer order entry, shipping, and production order release functions.

  Functions in this category must be tested thoroughly.

• Functions that are important, but the business can survive their loss for a few hours after the upgrade. Examples may include most inquiries and accounting functions, and high-visibility management reports, especially if management is made aware of the possibility of a one-time delay.

  Functions in this category should be tested as time and resources permit.

• Functions that can be broken for a day or two without serious impact. Examples may include reports, analysis functions, and end-of-period routines.

  Functions in this category can typically be spot checked.

Application Debugging After the Upgrade

If you properly execute your test plan, all critical functions will work after the upgrade. Less critical functions, however, may contain bugs. Be prepared to fix these bugs for a period after the upgrade. (Two weeks is usually long enough.) During this time, avoid scheduling new feature development. Have streamlined change control procedures ready, so that fixes can be installed quickly if a problem occurs.

Binary Level Support

Ingres 2006 provides support for applications built against previous versions of Ingres, back to and including Ingres 6.4.

You can run applications built with any version of OpenIngres 1.x or Ingres II 2.x, accessing an Ingres 2006 server, without rebuilding the application.

Applications built against Ingres 6.4 expect to access an older version of the Ingres message files. You can run applications built with Ingres 6.4 against an Ingres 2006 server, as long as either the application is running across Ingres Net, or Ingres 2006 was installed with the 6.4 message files. However, in all cases, we recommend that you rebuild all applications with Ingres 2006.