The upgrade template, all .p files it uses, and all .inp files it uses are only templates; you must check each file and modify it to suit your particular application. Following is a list of checks and modifications you must make before using upgrade; your application might require additional changes.
The UNIX version of upgrade is found in /usr/dlctk/samples/unix. The DOS version is located in the respective subdirectories of samples. The files that upgrade uses can be found in /usr/dlctk/samples.
The upgrade template performs three basic actions to upgrade an application at the user's site:
1. Loads the new .df file, which you created from your version of the upgraded database with the AdminDump Data and DefinitionsCreate Incremental .df File option
2. Rebuilds any indexes deactivated during the data definition load process
3. Compiles encrypted source procedures
The changes to the upgrade template for the data definition load stage (Step 1) include modifying upgrade.p (not the upgrade template) and the files it uses:
Set the system administrator ID and password appropriately in loginupg.p (or prepare a tool your users can use to set them).
Modify upgrade.inp to name the new .df file.
Test load_df.p (a standard OpenEdge Dictionary procedure). If you created a new unique active index, load_df.p asks if you want to deactivate the index. You need to add a response (Y or N) to upgrade.inp.
If you and your users do not freeze the database files, delete the call to freeze.p. (Leave the call to unfreeze.p in case your users ever freeze the database files without your knowledge.)
Modify unfreeze.p and freeze.p to include the correct filenames.
Check upgrade.log for any problems.
The changes to the upgrade template for the rebuild deactivated indexes stage (Step 2) are:
If you and your users will not be deactivating indexes, remove the _proutil command line from upgrade.
If you added a new unique active index, modify rebuild.inp to include the correct responses to prompts by _proutil $1 -C idxbuild. That is, test _proutil idxbuild on your database and add a line to rebuild.inp to answer each question appropriately.
Check rebuild.log for problems.
You might want to add a procedure to upgrade that checks rebuild.log and, if necessary, fixes duplicate key data and rebuilds the index again. Alternatively, you might want to check the .log file and just stop before compilation proceeds.
The changes to upgrade template for the compile encrypted procedures stage (Step 3) are:
Modify compile.inp to name the procedures to be compiled.
Modify the COMPILE statement in compile.p to use the encryption key you want.
Prepare to ship compile.p: either encrypt compile.p, possibly with the default key, or compile compile.p, thereby hiding your encryption key in the .r file. If you ship compile.r, it must be compiled on the target machine type. It can be compiled against any database because it does not reference any database files.The upgrade template is relevant when you want to distribute only new data definitions and encrypted versions of affected application procedures. However, you might choose to ship a complete new version of the database and application instead, as described in the following section.
Set the system administrator ID and password appropriately in loginupg.p (or prepare a tool your users can use to set them).