Using SQL Toolkit + SQL Compare to sync partial databases
Justin Spindler
Posts: 18
Good evening,
My company is currently using SQL Toolkit to package schema updates for our software. This works exceptionally well for our main software package. However we have several subsidiary products which each depend on their own database objects which are not a part of the core product. These subsidiary products are developed out of band from the main product so might not necessarily be capable of following the same release cycle as the main product.
My question is how could we make use of SQL Toolkit to deploy partial database schema updates? Would it be preferable to use a source database which only contains the target database objects or would it be possible to programmatically modify the resultant database snapshot to remove the other objects?
Any assistance in this matter would be appreciated.
My company is currently using SQL Toolkit to package schema updates for our software. This works exceptionally well for our main software package. However we have several subsidiary products which each depend on their own database objects which are not a part of the core product. These subsidiary products are developed out of band from the main product so might not necessarily be capable of following the same release cycle as the main product.
My question is how could we make use of SQL Toolkit to deploy partial database schema updates? Would it be preferable to use a source database which only contains the target database objects or would it be possible to programmatically modify the resultant database snapshot to remove the other objects?
Any assistance in this matter would be appreciated.
Comments
Provided you don't need to send any data and are concerned only with the schema, the SQL Toolkit os well suited to this task. The basic idea would be to take a 'snapshot' of the reference schema using SQL Compare, then putting the snapshot file and a custom Toolkit application into an Installer package and create a custom task that will synchronize the customer's on-site schema to the snapshot.
Using Visual Studio's Setup and Depolyment projects, you can create a new Installer Class to do your custom task. This installer class is called by the custom task and feeds the arguments to it. Here is an example of an Installer Class for synchronizing database schema as part of a deployment package:
Thanks for the quick response. Is your recommendation then to have the model database from which the snapshots are generated only contain the objects we wish to propogate?
Our current development databases for these subsidiary products contain objects for both our full product and those specific to the subsidiary product. There are cross-dependencies between the two sets of objects. The goal is to be able to merge the objects for the subsidiary product into a database containing the full product objects and then have subsequent snapshots to upgrade just those objects as new releases are cut.
I've toyed with the idea of using extended properties to mark the objects for the product and then using reflection to attempt to remove all objects except those marked with the extended property, but I assume that would be an unsupported method.
Effectively yes. The main product is developed using it's own database which only include the database objects that pertain to the main product. The other products are developed against copies of that main database which include database objects specific to that product. It is the maintenance of those database objects which we are interested in. We are currently using SQL scripts, and you know how much of a mess that can be.
This should work then. This Installer class code does not drop objects from the target database if they exist in the target database, but not in the snapshot. Actually, the project that I had written this for had a similar requirement. I have a databse where I keep a variety of tables that aren't related to the application I'm deploying. These tables are so inconsequential that they don't warrant having their own database, so when this project is deployed or upgraded, the installer leaves the tables unrelated to the application alone.
So this would be perfect for you -- create a snapshot of a schema usng SQL Compare for each of these modules, but only include the database objects that pertain to the individual module. You may have a bit of grief because you would need to build a separate database for each module in your development SQL server. SQL Compare snapshots must contain the entire database schema. If the customer adds the module to this application, only the module's database objects will be added,removed, or modified if the snapshot only contains the relevant database objects.
The other option would be take a snapshot of the entire database for the main application and all of the modules, and exclude the objects that you don't want to synchronize by name in the Toolkit project code. This would have the downside of making the application a bit more difficult to maintain, as if the main schema changes, you would need to ensure that the list of objects not to synchronize is maintained.