Re-Baselining via command line
pmenard
Posts: 5 New member
Has anyone attempted to automate re-baselining?
It seems as though SqlCompare can perform the tough work for us,
.\SqlCompare /server1:MyServer /database1:MyDatabase /empty2 /scriptFile:"{path}\baseline.sql"
... but there are some questions/concerns:
* Is there any way to get it to generate deployment scripts broken down by object or such, with a master ordering script? A singular script will likely be affected by ordering concerns. By-object scripts should hold up to non-changes better for source-control.
* Neither SCA's initial import (which does not have a PS equivalent) nor SqlCompare have a way to generate SCA-specific SQL features, such as CREATE ASSEMBLY scripts using SCA's binary replacement tags.
* Neither support carrying the proper migration tag "back" either. But that's just a short snippet of PS to make happen.
* Is there a way to ignore programmable objects? Given SCA's separate repository location for such, and given their life-cycle, programmable objects shouldn't need to be in the re-baseline.
Any other automation concerns people have already run into?
It seems as though SqlCompare can perform the tough work for us,
.\SqlCompare /server1:MyServer /database1:MyDatabase /empty2 /scriptFile:"{path}\baseline.sql"
... but there are some questions/concerns:
* Is there any way to get it to generate deployment scripts broken down by object or such, with a master ordering script? A singular script will likely be affected by ordering concerns. By-object scripts should hold up to non-changes better for source-control.
* Neither SCA's initial import (which does not have a PS equivalent) nor SqlCompare have a way to generate SCA-specific SQL features, such as CREATE ASSEMBLY scripts using SCA's binary replacement tags.
* Neither support carrying the proper migration tag "back" either. But that's just a short snippet of PS to make happen.
* Is there a way to ignore programmable objects? Given SCA's separate repository location for such, and given their life-cycle, programmable objects shouldn't need to be in the re-baseline.
Any other automation concerns people have already run into?
Tagged:
Answers
I have the following answers to your questions:
Is there any way to get it to generate deployment scripts broken down by object or such, with a master ordering script? A singular script will likely be affected by ordering concerns. By-object scripts should hold up to non-changes better for source-control.
Simple answer is no, SQL Compare will generate a single deployment script in dependency order.
Neither SCA's initial import (which does not have a PS equivalent) nor SqlCompare have a way to generate SCA-specific SQL features, such as CREATE ASSEMBLY scripts using SCA's binary replacement tags.
Sadly I do not believe this is possible.
Neither support carrying the proper migration tag "back" either. But that's just a short snippet of PS to make happen.
Yes, the tags would be missing and so the script generated would need to retain the existing baseline migrationID.
Is there a way to ignore programmable objects? Given SCA's separate repository location for such, and given their life-cycle, programmable objects shouldn't need to be in the re-baseline.
The user can filter out the programmable objects from the comparison used to create the baseline with SQL Compare. There are options to include or exclude them from the baseline. Further reading available in the help documentation.
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com