Hopefully this should put the ORM debate to bed, either use an ORM or don’t but please don’t access tables directly… There are obviously reasons behind all of this but if you follow this golden rule you will have a happy DBA and user base. Comments: Anonymous May 21, 2015 - 17:28 well - no one wants a sad well - no one wants a sad panda. Ed Elliott May 21, 2015 - 20:15

When you deploy your Sql Server code, there are two approaches, there is the manual way and the automated “compare & deploy” way. Manual The manual way is where you track what changes you have made and when you want to release, build a script or set of scripts which contain the updates. If you are modifying objects then you should use alter or drop/create and you need to manually create rollback scripts (should you need them).

BIML, you either love it or hate it - either you use it to totally generate hundreds of packages or a bucket load of data flow components all at the push of a button or you are perfectly happy using the SSIS editor, you can see how the package is made up and drag the little lines from one task to another and it is simple right, why bother using xml that is more complicated, you only need to create a single package with a few tasks on it, maybe a script component here or there.

I had the honour of talking at the excellent Sql Saturday Exeter this morning and wanted to share my slides and say thanks to the organisers, sponsors and everyone who came along to my session - I really enjoyed it and I hope you did to. The slides are available: https://the.agilesql.club/assets/talks/sqlsat15/SC-SSDT-CI.pptx Enjoy!

It is sometimes useful to be able to use sqlpackage.exe to create a script that can be deployed manually or still automatically but at a later date plus you may not want to give the user or process that does this sysadmin permissions just so that it can generate a deploy script. The permissions you need in this case are: SELECT permissions on dbo.__Refactorlog VIEW DEFINITION at the database level

Ok so you have created an SSDT project and are currently congratulating yourself on how awesome and cool you are but then you realise that your project is like an empty void, completely devoid of any emotion, love or joy - there is no schema and code in the project and you have all that lovely T-SQL sitting in a database, now how the hell do you get it into SSDT?

UPDATE I went and built this into my add-in for SSDT, more details https://the.agilesql.club/blog/Ed-Elliott/2015-11-17/Create-Stub-tSQLt-t… and https://the.agilesql.club/Projects/SSDT-Dev-Pack Generating tSQLt tests from a dacpac I use SSDT and tSQLt in my work and I am always interested in productivity tools to help speed up development and make it more streamlined, if there is something that can help us develop better or faster then we should use it. I have been a great fan of the DacFx for a while and the sample Dacpac Explorer seems to get quite a lot of visits with one mention from ms devs internally using it as a learning reference!

I was reading a white paper from a Sql Server tools vendor about how to integrate their tools with SSDT and while it was very interesting there were a couple of inaccuracies and I wanted to clear one of them up and also to help people understand that although SSDT is integrated to Visual Studio it is not tied to it in any way to TFS. You can use SSDT with any source code provider such as TFS, Git, Mercurial, Svn or Source Safe etc although you really should not use source safe for anything as it is the least likely tool to keep your source safe!

Calling all London/Sussex Sql Developers does this sound like you? Would you like to set up Continuous Integration or Continuous Deployment Do you want to get your databases under source control Have a high code coverage of your app but zero tests for your database code? Maybe you have thought how good it would be but you are a little lost at the options available, do you use SSDT and SqlPackage to deploy or SSMS with the Redgate source control addin, how do you deploy your code to different environments safely?

In part 3 of this series of blogs on “getting more agile” I am going to look at unit testing and why we need to do it. My code is perfect, I need no stinking tests Ah you are like me, my code is perfect as well, good point. blog end. actually…your code may well be perfect but: a) It only got perfect by you writing the code and writing a test script to make sure it worked (you did at least test it once, didn’t you?