How You Load Databases and Applications into the New Installation

After you create a development installation of the new Ingres and prepare your applications, you are ready to move your databases into the new development environment.

This process consists of the following steps:

1. Creating users
2. Moving databases
3. Moving catalogs
4. Moving Ingres Star databases
5. Compiling applications in the new environment

Create Users

After your new Ingres development installation is running, create any necessary Ingres users there. You may not need every user that exists in your current development environment. At a minimum, you must create any DBA (database owner) users.

Move Databases

Note: Before performing this task, you should have already created procedures for switching between the original version and new version development environments, as described in Create a Development Installation of the New Ingres.

To move a database from the original development environment to your new Ingres environment, use a simplified unload/reload procedure, as follows:

1. Setold and cd to a directory with enough space to hold the data; allow for the Ingres System catalogs.
2. Create a directory for each database that is to be exported.
3. Cd to the directory for the database that is to be exported.
4. Execute unloaddb against the original-version database to be unloaded.
5. Execute unload.ing to export the front-end catalogs and data.
6. Edit the unload scripts as follows:

   From Ingres 6.4: Edit the cp_ingre.in file and remove the lines:

   \include /ing64/ingres/files/iiud.scr

   \include /ing64/ingres/files/iiud64.scr

   Directory paths may be different.

   From Ingres 1.2: Edit the copy.in file and remove the lines:

   \include /ing12/ingres/files/iiud.scr

   \include /ing12/ingres/files/iiud65.scr

   Directory paths may be different.

7. Fix the system_maintained column name if necessary.
8. Setnew to the Ingres installation.
9. Create the database there, without any front-end catalogs, as follows:

   createdb databasename -f nofeclients

10. If the Ingres database name is not the same as the original database name, then edit the reload.ing script.
11. Execute reload.ing for that database.

    Note: Capture the output of the reload script in case errors occur.

12. Review the output of the reload for any reserved word conflicts. Correct any problems in the original-version environment and try again.

Capture Output of Reload Script (UNIX)

On UNIX, to capture the output of the reload script to a file, use "tee," as follows:

reload.ing |& tee /temp/reload.log

Move Catalogs

At this point, the front-end catalogs in the Ingres database are in the original-version format. To put them into new-version format, run:

upgradefe <databasename> INGRES

The above command assumes that you want the catalogs and data to be copied from the original development database to Ingres. If the data is not wanted, you can edit the scripts so that unloaddb does not copy certain tables.

Move Ingres Star Databases

For Ingres Star databases, unloaddb the CDB (the coordinator database, which usually starts with ii). This process unloads any locally stored tables that do not exist in other local databases.

Then unloaddb on the DDB (the distributed database, usually accessed by ddbname/star). This process unloads registrations and distributed view definitions.

The system_maintained Column Name

Databases created in releases prior to Ingres II 2.5 that contain the Metaschema module of system catalogs require an additional task when upgrading to Ingres II 2.5 using unload/reload.

These databases contain an extended system catalog ii_atttype with a column named system_maintained. As of Ingres II 2.5, system_maintained is a reserved word. Because of the keyword restriction, loading such a database into version 2.5 will fail. Release 2.6 and higher have a context sensitive keyword recognizer, and does not have the problem.

In Ingres II 2.5, the name of the system_maintained column is changed to sys_maintained. For the reload to work with 2.5, you must edit the original copy.in script to use the new column name. While you can also make this change using a utility such as sed, beware of inadvertently changing other uses of the system_maintained keyword.

Databases created with OpenIngres 1.x, Ingres version 6.4, and older do not usually contain the ii_atttype catalog. If you unload/reload a 6.4 database containing ii_atttype, you have to manually edit the file cp_ingre.in and fix system_maintained to sys_maintained.

Compile Applications

After you have successfully imported your databases into the Ingres development environment, you must compile your applications in that environment.

In most cases, you will want to make a copy of the application source code and libraries. Make sure that any compile scripts, linker command files, and the like point to the Ingres development installation, not the original development installation.

When you can successfully compile your applications with Ingres, you are ready to start testing.

Note: If you are upgrading from Ingres 6.4, check for the additional application issues under Considerations for Ingres 6.4.