That’s so funny Ken. I was just reading that email and thinking “I know that threads drift but I hadn’t realised that one had drifted that far”. It still seemed plausible ☺
Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ken Schaefer Sent: Tuesday, 3 November 2015 10:44 AM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: RE: Sql Server Patch Scripts Oops –I replied to the wrong email ☺ From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ken Schaefer Sent: Tuesday, 3 November 2015 10:42 AM To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>> Subject: RE: Sql Server Patch Scripts The other option might be to keep the Billion as a mere modem+NAT+router, then stick something behind that to handle your internal LAN and WiFi etc. I do that with a DLink 2890AL acting solely as a moden+NAT (turned off WiFi, single LAN uplink). I then have a Cisco SG-300 L3 switch (does routing, switching etc.) to handle the core LAN functionality, and a (getting old now) DLink DAP2310 WAP from their “business range”. I’ve found that to be a lot more solid than relying on the “SOHO” all-in-one boxes, which just seem to get overloaded and fall over every so often. The SG-300 has a good web interface, as well as excellent doco. The DAP2310 not so much, but still easy to configure unless you’re going into the more advance functions (like VLANs) where the doco starts to get ambiguous. Cheers Ken From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Burstin Sent: Monday, 2 November 2015 3:16 PM To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>> Subject: Re: Sql Server Patch Scripts 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<mailto: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<http://au.linkedin.com/pub/grant-castner> ________________________________ Date: Mon, 2 Nov 2015 14:48:56 +1100 Subject: Sql Server Patch Scripts From: tonyw...@gmail.com<mailto:tonyw...@gmail.com> To: ozdotnet@ozdotnet.com<mailto: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
