SSDT get your DB back in sync with your project
So I've been using SQL Server Data Tools (SSDT) in visual studio to manage database changes. I'm the only one really using it on my team right now. I had been working on a branch project in isolation for a while and the trunk database schema kept changing.
Today I am working in trunk (HEAD/master) again. So I need to switch to the trunk branch of my SSDT solution and get it back in sync with everyone else. I was amazed at how easy this was.
Simply do a database schema compare using a database with the most recent schema as the source and the SSDT project as the target. Run the update to make changes to all the SQL files in the target (the project). Then you can commit all those changes to your source control and VOILA! - Your SSDT project is back in sync.
Now I can develop my own schema changes and generate the change scripts easily. Sweet!
Today I am working in trunk (HEAD/master) again. So I need to switch to the trunk branch of my SSDT solution and get it back in sync with everyone else. I was amazed at how easy this was.
Simply do a database schema compare using a database with the most recent schema as the source and the SSDT project as the target. Run the update to make changes to all the SQL files in the target (the project). Then you can commit all those changes to your source control and VOILA! - Your SSDT project is back in sync.
Now I can develop my own schema changes and generate the change scripts easily. Sweet!
Just a note. I have since stopped using SSDT since using Entity Framework with Code First is so easy. You can even script out the database changes by typing 'update-database -script'. So I really don't need SSDT anymore. There were some nice things about SSDT, like when changing a DB column name, knowing all of the objects that would be affected by that change (like dependent views, procs, etc.)
ReplyDeleteInstead now, I have a simple SQL Server Management Studio solution with all my SQL being maintained in a git repo. (Command line git)
Just a note. I have since stopped using SSDT since using Entity Framework with Code First is so easy. You can even script out the database changes by typing 'update-database -script'. So I really don't need SSDT anymore. There were some nice things about SSDT, like when changing a DB column name, knowing all of the objects that would be affected by that change (like dependent views, procs, etc.)
ReplyDeleteInstead now, I have a simple SQL Server Management Studio solution with all my SQL being maintained in a git repo. (Command line git)