Comments
2 comments
-
Looks like the way to do this is to run SQL Compare stand alone, rather than trying to do this from SSMS. Then you can pick the scripts as the source and a blank database as the target. -
Hi there,
Thanks for your post. Your best bet would be to pick a current version of the DB and then link that to a blank folder in TFS using SQL Source Control. Once you commit that into TFS using SQL Source Control, all your other developers an link up to the same root folder in TFS and perform a "Get Latest" using SQL Source Control, which will populate their blank DB's with the schema you checked in TFS.
More info on this can be found using the below link:
http://www.red-gate.com/supportcenter/Content?p=SQL%20Source%20Control&c=SQL_Source_Control/help/2.2/SSC_WE_Setting_up_TFS.htm&toc=SQL_Source_Control/help/2.2/toc.htm
HTH!
Pete
Add comment
Please sign in to leave a comment.
We expect developers to work with local SQL databases, using SQL Compare to compare against a central repository in TFS and check in their changes.
We've succeeded in creating the set of scripts for the initial database schema and this is checked into TFS. My question is - how does a developer do their initial setup to create a local database whose schema is the same (initially) as the central repository scripts?
I can link a local database to source control, but then SQL Compare seems to think that it needs to delete all the tables etc. from the repository, rather than create them in the local database. It doesn't seem to be possible to do a 'Set as target' on a blank database then pick a source control repository as source. What am I missing?