Processing mode

For each pre-upgrade and post-upgrade script, you must set a Processing mode that indicates how the script must be run on the target machines:

Processing Mode	Explanation
Rules Engine	The SQL commands must be executed as if by default from the SQL Command dialog in the USoft application. All constraints and other checks execute in response to the data manipulation.
Disable Rules	The SQL commands must be executed as if from the SQL Command dialog after calling the DeactivateAllConstraintChecks() action. Constraints and other checks do not execute. One difference with the "rdbms" processing mode is that logical view names are recognised and subtype constellations resolved as if the statement(s) was normally executed by the Rules Engine. Another difference is that SQL constructs known to the RDBMS but not to USoft will raise errors.
Database	The SQL commands must be executed directly by the RDBMS, using an RDBMS-supplied utility.

When you define Processing Mode, always consider the Rules Engine option first: data integrity is automatically safeguarded only if you run against the Rules Engine. A reason to choose a different processing mode could be that it speeds up the upgrade operation in cases where you have large data volume on target machines and you are sure that, logically, you do not need the Rules Engine action.

Processing Mode = Database has an effect on script checking. The script will be set to Checked = Yes, but no checking will actually take place. This applies to all aspects of script checking, including SQL syntax checks, checks against the data model, and expansion of any source variables and path placeholders.

If Processing Mode is other than Database, full script checking will be performed. The difference between Processing Mode = Rules Engine and Processing Mode = Disable Rules has no effect on script checking.

Processing mode, releasing

When you come to release your upgrade scripts, the choice of Processing Mode is reflected in the generated script file names as follows:

Processing mode	Indicated in script name by	Example generated filename
Rules Engine	"ure.active"	MYAPP.110.pre.ure.active.sql
Disable Rules	"ure.disabled"	MYAPP.320.post.ure.disabled.sql
Database	"rdbms"	MYAPP.320.post.rdbms.sql

The processing mode is also printed as a comment at the top of the contents of each generated script.

Processing mode, executing

The instruction to administrators or DBAs who are to execute upgrade scripts on target machines must be different depending on the Processing Mode indicated in the script filename and at the top of each script.

Processing mode = Rules Engine

The script must be run by opening a USoft client/server instance, opening SQL Command in it, executing the script contents, and committing the transaction. If it is unacceptable to open a USoft client/server instance on a target machine, a custom automation solution must be implemented around the script code, for example:

•The script can be run inside a Windows command which is a call to usd.exe.

•The script can be executed by a Rules Service running as a Windows service.

•The script can be wrapped in a USoft Batch Job.

Processing mode = Disable Rules

The top of a generated upgrade script file with Processing Mode = Disable Rules has the instruction:

action DeactivateAllConstraintChecks( )

In order to run such a script successfully by opening a USoft client/server intance and opening SQL Cmmand in it, the "Allow_Disable_Constraint" parameter of the applicable Deployment Configuration in USoft Authorizer in the target database account must be set to True for the Client/Server context. Delivery Manager facilitates setting or unsetting this parameter by running the "Allow disable constraints" action, but only for database accounts declared in, and directly accessible from, Delivery Manager. Alternatives include setting this parameter for a different context (Rules Service or RunBatch) and making arrangements so that the script may be run accordingly.

Processing mode = Database

The script must be run against an RDBMS utility in the same way as the create-tables script (if any). This type of script is usually easy to understand for DBAs, because they are used to running scripts on target machines in this mode.