Typical Upgradedb Problems

Here are some typical problems you may encounter when using the upgradedb utility.

The upgradedb utility starts to process, and then hangs with no error indication.

This condition is probably caused by the Remote Command Server interfering with the upgradedb process, which is likely if you are upgrading to Ingres II 2.0 instead of Ingres 9.0. Use the rmcmdstp command to stop the Remote Command Server.

You can use Configuration-By-Forms or Visual Configurator to turn off the Remote Command Server until the upgrade is finished: select Remote Command Server and use EditCount to set the startup count to zero.

The following message occurs: “Product name has been made uninstallable by an incompatible dictionary upgrade.”

This message is caused by extra or incorrect rows in the front-end catalog ii_client_dep_mod. The rows may have been created by very old versions of Ingres. You can ignore this message.

The following message occurs shortly after the upgradedb utility starts processing a database: “E_SC0206 An internal error prevents further processing of this query.”

This message is seen when upgradedb –all is used, and the database data ROOT location is not the same as others processed in the same upgradedb run. The errlog.log shows the message ”E_DM9004_BAD_FILE_OPEN” referencing a filename: aaaaaaaa.cnf, shortly before the E_SC0206 message.

This message has occasionally been seen in various versions of upgradedb. Simply rerun upgradedb for the one failed database, and continue the upgrade.

Warning messages appear after upgradedb announces “Reloading query- tree objects.”

Although the messages are warning messages and the database is shown as having been upgraded, some views, permits, or other objects have been recreated incorrectly and are missing from the database, so treat these warnings as if they are fatal errors.

Refer to the following files found in the directory $II_SYSTEM/ingres/files/upgradedb/UPGRADEUSER, where UPGRADEUSER is the user who ran upgradedb, for example “ingres”:

SQL terminal monitor script, where dbname is the name of the database being upgraded and nn is the sequence number of the upgrade for that database starting from 1.

Output from dbname.inn, where dbname is the name of the database being upgraded and nn is the sequence number of the upgrade for that database starting from 1.

You can identify the problem by inspecting the messages found in upgradedb.log. Data is appended to this file, so more than one entry may exist for dbname.

A possible cause of failure is that a table used in a database procedure has been dropped and when that procedure is being recreated as part of upgradedb, the program fails due to table not found.

You may be able to resolve the problem by inspecting the output file (dbname.onn) and then editing the dbname.inn file. Make copies of the files before making changes. After you have made the changes to the dbname.inn file, rerun it using the Terminal Monitor.