Visual Studio Database Projects and General Use
-
We'd like to start using Database Projects to manage our SQL Server code in the same structured way we do the other code. We have a separate domain for development, and we also pass any changes to production to a third party. Is there a good resource (book, blog etc) on the day-to-day usage of these? One issue I've got at the moment is that the comparison result script is very protective (which is good). In my case its warning about tables that are being altered could contain data. Now I know that it doesn't matter as these are working tables, so it doesn't matter if they 'loose' data. Should I be taking the script and then altering it to suit the situation, or have I missed something earlier that would have made VS generate a better script? Also would people say that the comparison script is the best way to bring a database to the right version or is there a better way? Note the implementers have little to no understanding of the purpose of the database.
-
We'd like to start using Database Projects to manage our SQL Server code in the same structured way we do the other code. We have a separate domain for development, and we also pass any changes to production to a third party. Is there a good resource (book, blog etc) on the day-to-day usage of these? One issue I've got at the moment is that the comparison result script is very protective (which is good). In my case its warning about tables that are being altered could contain data. Now I know that it doesn't matter as these are working tables, so it doesn't matter if they 'loose' data. Should I be taking the script and then altering it to suit the situation, or have I missed something earlier that would have made VS generate a better script? Also would people say that the comparison script is the best way to bring a database to the right version or is there a better way? Note the implementers have little to no understanding of the purpose of the database.
We use them where I work to version stored procedures, permissions and other objects in source control. We also use the generated script(s) to deploy changes. The build process includes a task to compile the db project(s) and generate a diff script for the target environment, and then all the application files, SQL scripts, etc, are pushed to a staging folder on the network, ready for deployment. I personally alter the generated scripts when I come across the warnings of existing data being lost. However, I don't know if that's standard/best practice or not - that's just how I've always done it.
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
-
We use them where I work to version stored procedures, permissions and other objects in source control. We also use the generated script(s) to deploy changes. The build process includes a task to compile the db project(s) and generate a diff script for the target environment, and then all the application files, SQL scripts, etc, are pushed to a staging folder on the network, ready for deployment. I personally alter the generated scripts when I come across the warnings of existing data being lost. However, I don't know if that's standard/best practice or not - that's just how I've always done it.
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.
-
Thanks for that, this is what I'm thinking will be the case too. VS can't *know* everything, so it makes sense that manual alteration of the diff scripts is required.
Right. It can be a bit tedious. I've been working on a project for a few months, an existing application. The new enhancements/features required that we split some existing tables out (moving a field from one table to a new table). When setting up the deployment, I had to alter the generated diff scripts quite a bit.
djj55: Nice but may have a permission problem Pete O'Hanlon: He has my permission to run it.