Recently, I started looking for a new position, and fortunately that search has concluded successfully. I thought I’d take the opportunity whilst serving my notice to share some thoughts on my interactions with recruitment agents, both during this search (which didn’t take long) and at other times when I wasn’t actively looking.
Continuing the section on trying to get a large legacy database imported into an SSDT project that actually builds, we’re at a point now where we should have genuine reference issues to clean up; all our cross database references should be sorted via a database reference to a DACPAC (with or without changing everything to use SQLCMD variables or not).
At this point, we’re going to get really annoyed with all the legacy, simply doesn’t work anyway, code left in our database over years of not tidying up. Technical debt sucks.
Lets look at some of the things that are going to annoy us! Continue reading
Continuing my series on SSDT based deployments, in this part, I’m going to look into something that’s not entirely SSDTs fault, but I’m sure could be less painful: importing pre-existing databases into an SSDT project. Particularly ones that have cross database references, or three part naming of objects (database.schema.object) which effectively make them a self referencing object.
Firstly, I want to state that I don’t really like cross database references. In a world of filegroups, schemas and so on, I think a large number of multiple database setups should probably just be merged into a single db. I address quite a few of these thoughts in my article SQL Server – When is a new database appropriate?
However, I’m also aware that this refactoring takes time, and that the damage is already there. Add this into the fact that these databases will most likely not have been developed with any source control, and so somehow we have to drag them, kicking and screaming, into TFS and an SSDT project…..
Motoring along in the SSDT based deployment series, in this post I’m going to look at one particular publish setting and how it behaves, which is my fourth bug bear with the SSDT deployment function:
4. Block incremental deployment if data loss might occur.
In my previous post, I alluded to some of the issues I’ve found using SSDT based deployments into a live server, with lots of data. For me, these are the configuration options that could cause significant pain performing a live release using the SSDT dacpac publish, that don’t cause a problem in development.
In this post, I’m going to look at the Database settings, and in particular, how filegroups behave when you perform a deployment.
Continuous integration is rightly a hot topic in today’s world where the time desired to bring products to market is ever shrinking. Database lifecycle management is a key part of this, and generally database professionals have been slow to adopt continuous integration methodologies, often hiding being frameworks such as ITIL to point to issues of safety and caution.
It’s undeniable that a database release is a much more complicated beast than an application release, due to one really key part of a database: data. Unlike an application, you can’t just destroy your database and start over with a clean slate at every release; if you did, your data, and likely your business, will be gone. Whoops. This is where I start getting a little nervous with some of the options available in SSDT deployments, such as this one:-
From SQL Server 2008, the datetime2 datatype was introduced, with greater flexibility for precision and also with an added bonus that it was truly compliant with ANSI and ISO 8601. For more info, read up on the Books Online entry for datetime2.
While not everybody (including Microsoft!) have adopted this datatype, if you really want accuracy for your datetime columns, you’re better off switching to this type, and I know quite a few implementations that do.