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 >
