Post Deploy with Test Static Data
chad
Posts: 2 New member
I have a table with static data and a script that inserts a few more records for non-prod servers. Those extra records are not part of the static data in source control.
I was thinking that these steps would happen during each deployment:
1. SQL Source Control syncs data and deletes the extra test records.
2. Post deploy script re-inserts the test records again.
But instead I am getting a PK violation because the post deploy script is inserting an existing test record. This is happening because the post deploy script is running before the data syncing.
Yes, this is not fully "idempotent" script, but it would be fine if it were only run once per deployment and only after all syncing tasks have finished. Should I assume that post deploy scripts are run multiple times for each deployment or am I missing something?
I was thinking that these steps would happen during each deployment:
1. SQL Source Control syncs data and deletes the extra test records.
2. Post deploy script re-inserts the test records again.
But instead I am getting a PK violation because the post deploy script is inserting an existing test record. This is happening because the post deploy script is running before the data syncing.
Yes, this is not fully "idempotent" script, but it would be fine if it were only run once per deployment and only after all syncing tasks have finished. Should I assume that post deploy scripts are run multiple times for each deployment or am I missing something?
Tagged:
Best Answer
-
Sergio R Posts: 610 Rose Gold 5Hi Chad,
In SQL Source Control this will not work because the static data will not be reset: the software sees the TESTROW as something to commit to the repository so it won't get the static data again from the repository.
The solution, in this case, is to write your Post-Deployment with a guard clause that only inserts the rows if they do not exist:<div>IF(@@SERVERNAME = 'TESTSERVER') </div><div>BEGIN <span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Roboto, "Helvetica Neue", Arial, sans-serif;">IF NOT EXISTS (SELECT * FROM [dbo].[MyTable] </span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Roboto, "Helvetica Neue", Arial, sans-serif;">WHERE [MyField1] = 'TESTROW') </span><span style="background-color: transparent; color: inherit; font-family: Roboto, "Helvetica Neue", Arial, sans-serif; font-size: inherit;">BEGIN </span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Roboto, "Helvetica Neue", Arial, sans-serif;">INSERT INTO [dbo].[MyTable] ([MyField1]) VALUES ('TESTROW')</span></div><div> END <span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Roboto, "Helvetica Neue", Arial, sans-serif;">END</span></div>
Please note that if these are not development databases then the best practice is to use a deployment tool (SQL Compare or SQL Change Automation Powershell) rather than SQL Source Control (in which case the advice I provided in my first reply would apply).Sergio
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools
Answers
Post-deployment scripts are run after static data is deployed and only once per deployment.
What you are trying to do should work, though it would probably be best not to use static data on that table and use SQL Data Compare to sync the data. If you use SQL Change Automation Powershell for the deployment you going to get Post-Deployment Schema check failures with this approach.
What tool are you using for the deployment?
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools
The error is happening during the "Applying Schema changes to database" step. This seems to be happening before the data is synced. Is that the case or am I missing something?
If you want, here is the code to create that error:
Static Data:
Post-Deployment Script:
Running the first time is successful. Running the second time results in a primary key violation.