Configuring a re-usable .cmd script: optional parameters

May 20, 2019
|By Thomas Pryce

Search Knowledge Base by Keyword

Created OnMay 20, 2019
byThomas Pryce
< Back

Several optional parameters can be defied in the re-usable .cmd script. The optional and mandatory parameters are listed in the table below. Mandatory here means that you should edit the parameter for each and every Subset job. For all other parameters, there will either be a default, or it is wholly optional.

Many of these parameters will already be present in the re-usable .cmd script, and you simply need to edit them. Perform a find in the script to locate the existing parameter and specify a new one. If not, simply the standard code to the script and specify the parameter.

Note: You might specify parameters for a .CMD script for an Action or set of Actions that you are likely to re-run in future. In this instance, you might want to keep a copy of this script for quick and easy re-use. You can then also keep a ‘master’ script for new or one-off Actions.  A master script will typically contain the location of the Control Spreadsheet and .vip flow. You simply then need to edit the Action and any optional parameters for each new Action.

Parameter NameMandatory?DescriptionExamples
-fp=YesSpecifies the location of the .vip workflow that will execute the Subset Action.-fp="C:\Users\VIP1\Documents\Subsetting documentation\SQLSubset.enc.vip"
-logDir=YesSpecifies the location into which the Log File folders will be created.-logDir="C:\Users\VIP1\Documents\Subsetting documentation\Subset Files"
parActionYesYou must specify the Actions that the script will run. These are the Subset Actions listed in the Process Overview.

Possible actions are BUILDMODEL, SUBSET, ADDPKEYS, ADDFKEYS, DELETEORPHANS, DROP, DROPFKEYS, DROPPKEYS, GETKEYS, PREPENV, TABLES, TRUNCATE, VALIDATEFKEYS and VALIDATEPKEYS.

Multiple actions can be executed in one run. Simply comma separate the required actions.		-parAction=”TABLES,GETKEYS”
parCleardownReportNoThis specifies whether the Action(s) will empty the Subset Report file when one already exists.

If set to True, the Subset Report file will be overwritten.

If set to False, then the Report will be appended to the end of the existing Subset Report File. 		-parCleardownReport=False
parCommandTimeoutNoTime (in seconds) before a SQL command times out. Defaulted to 600.- parCommandTimeout=400
parContolExcelYesYou must specify the location of the Control Spreadsheet that will be used to drive the action.-parControlExcel=” C:\Users\VIP1\Documents\Subsetting documentation\VIPsubsetSample_init.xlsx”
parDatabaseTypeYesMySQL, SQL Server, Postgres or Oracle.-parDatabaseType="SQL Server"
parPrepenvAllTablesNoIf set to “False”, it will only PREPENV will only create tables in the Staging Database when are needed to fulfil the Subset Criteria and relationships in the Database Model.

If set to “True”, it will create all tables set to “Active” in the Tables sheet.

If set to “False”, you must have run your BUILDMODEL.

Defaulted to “True”.		- parPrepenvAllTables=False
par1, par2, par3, par4, par5NoAnother way to specify Substitution Variables.

If specified as parameters, these values will override the Substitution Variables specified in the Control Spreadsheet.

This provides a quick way to change the values when running an Action.

Substitution variables available for use in SQLCriteria and FoundCriteria.		-par1=”onpromotion”
parReportFileYesThis specifies the name and location of the Subset Report. The file name is defaulted to SubsetReport.txt

To set the location where the Subset file will be generated, specify the whole file directory.

If naming the file, you should include the file extension in the file name.		-parReportFile=” C:\Users\VIP1\Documents\Subsetting documentation\SubsetRun2.txt”
parOverrideBuildmodelRequirementNoThis parameter allows the SUBSET action to run even if the flow reports that the database model has changed. Defaulted to False.

When the SUBSET action, VIP first checks whether the database model is up-to-date. They use the HashCodes sheet to check if the Control Spreadsheet has been changed in a way that will effect the database model. If BUILDMODEL has not been run since such a change, you will need to re-run BUILDMODEL to register the updated model. Alternatively, you can set this parameter to “True” to run SUBSET Action anyway.		- parOverrideBuildmodelRequirement=True