Before you start, this is NOT a post about Multiple Active Result Sets, so don\’t get too excited (but don\’t go away yet either – hear me out).
A perennial challenge between the DBA and his/her development colleagues is that they speak a different language and some things are bound to get lost in translation. A good team will use many different strategies for coping with this, other people will constantly be at loggerheads. The DBA wants to use native tSQL, the developer C# CLR stored procedures. The DBA wants to use out-of-the-box functions in SSIS, the developer .net code. We\’ve all seen this.
Unfortunately, Microsoft don\’t make it any easier for teams to begin to understand each other, because they use differing constructs in different tools to accomplish the same thing.
I\’ll explain:
Situation arose today where it was needed to get the day number for a given date. Simple enough to do in tSQL –
Nice and simple. What really irritated was that to accomplish the same thing to add a derived column to a pipeline in SSIS, you\’ve got a different syntax:
(Note the requirement for the double quotes around the DATEPART specification)
Is this really a problem ? Not so much, but it certainly doesn\’t help when you\’re trying to convince a dyed-in-the-wool tSQL guy that they should really take a look at this pipeline ETL stuff called SSIS because it\’s really easy….
All I\’m pointing out here is that maybe things could be a little better integrated. SQL2005 introduced CLR and .net scripts inside stored procedures, but I don\’t see anything allowing tSQL to drive things the other way round.
Please could someone prove me wrong about this ? Is there such a \’killer app\’ that will let DBAs and Developers perhaps not talk the same language, but at least allow them to use a common thesaurus ?
The Modern Dataist 