I do this as well with projects. It works well if you only have to deploy to a couple of databases. If you have many databases (>3) then I find the migrations approach described by Grant works very well.
On Mon, Nov 2, 2015 at 3:15 PM, David Burstin <david.burs...@gmail.com> wrote: > We use SQL Server projects for patching, version controlled with git. > > For schema changes, we run a compare on the project and the dev database > (assuming that is where the schema changes are) and create an upgrade > script from that. > > For actual data changes to be applied, we create separate scripts in the > sql project specifically for those. > > This seems to work pretty well for us. YMMV. > > Cheers > Dave > > On 2 November 2015 at 14:53, Grant Castner <gcast...@outlook.com.au> > wrote: > >> Hi Tony, >> We use dbup (https://dbup.github.io/) - it allows you to create a small >> visual studio project so that you can track scripts as well as check them >> in. >> >> Cheers, >> Grant >> >> >> Grant Castner >> Phone: 0458 770 749 >> Twitter: https://twitter.com/grantcastner >> LinkedIn: au.linkedin.com/pub/grant-castner >> >> >> ------------------------------ >> Date: Mon, 2 Nov 2015 14:48:56 +1100 >> Subject: Sql Server Patch Scripts >> From: tonyw...@gmail.com >> To: ozdotnet@ozdotnet.com >> >> >> Hi all, >> >> Almost every system I have developed has been against a SQL Server >> database, and every environment has needed to be patched as greenfields >> projects introduce new changes. >> >> The reality is that I have found providing patch scripts for sql server >> quite problematic and have never been very happy about what we do to apply >> patch scripts. >> >> I want to know what scripts have been applied to a database, and I also >> want to know that scripts applied are transactional (that is, if a script >> "breaks" when applied, nothing has changed.) I also want to be able to add >> data to be inserted into tables to my scripts. >> >> What are people currently doing to solve these issues? >> >> Warm regards, >> Tony >> > >