Processing order |
|
|
|
Choose "Pre-upgrade" to indicate that your upgrade script must run before the create-tables script. Choose a unique Script Seqno for each Pre-upgrade script. This Script Seqno determines the order in which operators will run the Pre-upgrade scripts between them. Pre-upgrade scripts are given an external sequence number in the range 100-199. Choose "Post-upgrade" to indicate that your script must run after the create-tables script. Choose a unique Script Seqno for each Post-upgrade script. This Script Seqno determines the order in which operators will run the Post-upgrade scripts between them. Post-upgrade scripts are given an external sequence number in the range 300-399.
The choice of processing order dictates against which database account a script is checked: •Pre-upgrade scripts are checked against the database account set as the "Source for pre-upgrade check" for the script's application. •Post-upgrade scripts are checked against the database account indicated as the "Source for post-upgrade check" for the script's application. It is easy to determine the "Source for post-upgrade check" database account because this must be the account with the latest state of the data model, ie., the Development account. Having a "Source for pre-upgrade check" available requires more planning. This must be a database account that has the state of the data model at the time when the application was last released to other machines. This database account could be a Test or Acceptation account or an account especially maintained for checking Pre-upgrade scripts. If you do not wish to keep 2 different sources for script checking, you can set both attributes to the same (Development) account. However, remember that in this situation, Pre-upgrade scripts will not be successfully checked if they refer to objects that have become obsolete in the post-upgrade data model. Otherwise, consider if it is possible to do without Pre-upgrade scripts altogether.
See Also |
|