Spikeh'd

So yesterday I made the second ever major technical boo-boo of my career - I accidentally ran a dynamic "DROP TABLE" script on an extremely large, high-availability system. The last time I did something of this magnitude was literally when I first started out with T-SQL, and I ran a load of DROP / CREATE PROC statements on a similar sized system, right in the middle of rush hour; instantly breaking the 500 of so clients that were connected to it. Obviously this kind of thing is very embarrassing, not to mention the massive inconvenience caused throughout the departments using the system. Luckily the database is backed up hourly (thank you Mr DBA), and although I made the mistake 6 minutes before the next back up, the impact was relatively minimal due to the main user's being in a departmental meeting. I'm blogging to outline my mistake and document changes to my T-SQL script, which up until 13:34 yesterday, made my life considerably easier and I thought was the dog...

Following on from my last post  complaining about MSSQLMS UI code generation , I thought I would back it up with a few T-SQL scripts that generate code that I actually want to see. I'm currently developing a large scale, real life application using my new .Net 4.0 nTier framework , so I've decided to make my life a little bit easier by generating the boring old CRUD stored procedures with some funky T-SQL scripts. I'm also currently looking in to Visual Studio's T4 code generation tools to help me create my business objects, as most of those will also be fairly standard - though I still need the flexibility to change them (and guarantee that a code generation tool isn't going to overwrite my changes) once the templates have all been created. Let me start by saying I'm usually against the use of the 'sp_executesql' stored procedure due to the additional overhead created by executing dynamic SQL. In this instance however, I'm happy to use it becaus...

Since the start of my career I've used SQL Management Studio (or Query Analyser in MSSQL 2000) to manually create my MSSQL database objects via code. This is a practice I have vehemently defended a number of times - being told that producing objects with the UI tools is "quicker" and "easier". Subjectively, I have to agree with this statement - any kind of well designed UI generation tool is almost certainly going to be quicker than writing a load of CREATE statements by hand... there is of course, a caveat. I tend to find that developers who do not fully understand RDBMS' (which is a vast majority, unfortunately), or do not enjoy writing databases always take the quick and easy approach. The problem with allowing a UI to generate code is that a large portion of it is unnecessary, and it's sometimes difficult to read. This is true of most generator engines, including those found in .Net. In terms of SQL generation, hopefully these code snippets will ...

Recently I've been working on a small project that uses LINQ to SQL as it's data layer (it's a very simple model) and contains two presentation projects - a web form application for the front end and an MVC 3 administration panel. When playing with the unobtrusive validation engine, you'll find many examples on the 'net telling you to decorate your model with various attributes from the  System.ComponentModel.DataAnnotations namespace. Now, I ran in to a bit of an issue with the LINQ to SQL objects - they're generated dynamically. I could add the attributes, but they would be overwritten any time I made a change to my DBML file. So, after a bit of searching I came across the MetaDataTypeAttribute in the same namespace. This attribute allows you to create a completely separate, standard class and define it as a Meta Data container for another class. Neat, hu? Well, I quickly ran in to my second issue - I could create my separate class, but I still had to...