Static Scripts¶
Static scripts are normally stored in your version control system and are referenced via a relative path in the deployment section of your template definition. They allow you to trigger the inclusion of these static scripts and various points in the execution of the deployment scripts. Typically they are used to disable and enable constraints so that data integrity is verified after execution of a script or set of scripts. DATASTAR runs all changes under a transaction therefore any failure will rollback the changes including any disabled constraints.
NOTES:
Oracle: Do not use any static scripts that contain DDL with Data Scripts (for example enabling and disabling constraints). Oracle Database issues an implicit COMMIT before and after any data definition language (DDL) statement.
SqlServer: If you set the Version attribute in your template components to version 2, DataStar will use a new format where the DELETE is removed from all MERGE statements and instead the deletes are handled at the end of the script in reverse order. This avoids potential foreign key constraint violation errors and removes the need for the static disable and enable constraints scripts.
Automatic Reversal Feature¶
When using the automatic reversal feature your static scripts should be annotated with a metadata tag so that it can be identified as a static script. In this case it won't attempt to create a reversal script but will just include it unchanged in the reversal scripts.
-- Metadata: {"static":"true"}
ALTER TABLE [TABLE_A] NOCHECK CONSTRAINT ALL
ALTER TABLE [TABLE_B] NOCHECK CONSTRAINT ALL
When running in reversal mode you may find that the order in which the disable and enable scripts run does not work due to some cross dependencies between different components. For example if I have component A that has a foreign key reference to another component B, I would normally create the dependency order such that B runs before A, in a normal deployment the the disable constraint order would be correct. However in reversal mode where I was deleting rows I would not be able to re-enable B constraints until I had also processed the reversal for A. To solve for this problem you can add an additional tag to the metadata in the enable and disable scripts to tell DataStar to shift the script to the start or end in a reversal scenario so that all the disable constraints run first and all the enable constraints run last (note this only applies to reversals and only where the metadata is specified).
-- Metadata: {"static":"true","rollbackShift":"start"}
ALTER TABLE [TABLE_A] NOCHECK CONSTRAINT ALL
ALTER TABLE [TABLE_B] NOCHECK CONSTRAINT ALL
Or