Need guidance on using this product

My team uses TFS religiously for Visual Studio work. Just now getting started with this SQL plug-in. I would appreciate some guidance from the experienced folks out there.

If I link a database that is on our UAT database server that is currently in development, and not in production yet at all, from SSMS...how do I handle it when we go live and move the database to the production SQL Server instance? Do I unlink the UAT database from TFS and then link the production version? How does that work with the database artifacts that are left in TFS after linking? Just not sure what is best practice. The paradigm is a little different than with our Visual Studio code, which we can work in all day without impacting the production code because the code is published to a separate web server. In the case of this tool, we are linking a database right to the place where the artifacts live. We do have the SQL Compare tool as well, which adds to the confusion.

Thanks in advance.

Comments

  • Hi,

    SQL Source Control is designed as a development tool and although it's possible, I wouldn't recommend directly linking your production database. For deploying your development database to production I would suggest that using SQL Compare is a better option. SQL Compare integrates with SQL Source Control - in SQL Compare you can choose "Source Control" as a data source. You could pick your repository and compare it against your production database, then use SQL Compare to deploy the changes.
    Software Engineer
    Redgate Software
Sign In or Register to comment.