Ok. So setting up CLR routines in SQL 2005 can be a bit of a pain but once you get past that there is a lot of cool stuff you can do. Allot of developers I know get a bit bent out of shape around CLR routines as they are not the fastest way of doing most things but there are actually sounds reasons for doing CLR routines even though they might be slower then T-SQL for core database tasks. One of the primary reasons in my mind for adding the CLR technology is that you get the ability to turn SQL into an application server. So my favorite case for CLR routines in the db is pushing Credit Card and Financial processing in to the database layer. Anyway for now I wanted to just note one little issue around CLR routine debugging.

So I use this ubber 64-bit monster as my desktop machine. Its got ALL the bells and whistles but once I managed to get my CLR routine in the db for importing a huge block of XML and I figure a CLR routine written in C# is going to take months less to write then trying in vain for weeks todo do the process using SQL. So the ideal is I have this CLR routine that uses XML Serialization to import my XML blob and then it processes this into data into my data base. It seems like it works and I write my unit test script and try to run it and it steps into the t-SQL in the debugger and I get to my break points and then it trys to step into my C# code and the entire thing blows up. And I don't mean my routine blows up, Visual Studio blows up, something about 32-bit code and going from 64-bit to 32-bit. In any case there is an easy fix. Just spin up the 32-bit 'Visual Studio Remote Debugging Monitor' and it all works like a finely oiled machine. Start - All Programs - Microsoft Visual Studio 2005 - Microsoft Visual Studio tools - Visual Studio Remote Debugging Monitor' you can tell you have the right one as you want the one that doesn't say (64-bit) by it.