Killing a Yukon myth

About once a week or so I get the question what the strategy will be with our O/R mapper LLBLGen Pro in relation with Yukon (SqlServer 2005): will the O/R mapping code run totally inside the database server or will it be running outside the database, like with SqlServer 2000. This is actually a question that I can imagine is puzzling a lot of developers, also the ones not using any O/R mapper at all: will we be able to run the DAL inside Yukon and with that benefit from the close connections between DAL code and database server, and how do we call this DAL?

Before I read the Yukon documentation, I was assuming, based on the marketing material available, I was able to run my assemblies inside Yukon, instead of running them outside the database. Recently I thought more about this and wondered: but how am I going to call the methods on the various classes, like myCustomerCollection.GetMulti(filter) ?

I installed Yukon beta 2 and start reading the documentation. It turned out: what I assumed was wrong. You can't move your DAL inside the database server. You can write stored procedures in C#, you can call .NET code from your stored procedures, you can create user defined types using .NET, you can write user defined aggregate functions and you can write user defined functions, but you can't run a complete DAL inside Yukon.

Furthermore there are a couple of restrictions placed on the .NET code running inside Yukon, especially related to static methods. The documentation sums them up quite nicely, but it comes down, as far as I can see it, that it's not possible to move the DAL assembly (or assemblies) inside Yukon and call the methods from a C# stored procedure for example (to work around the limitations that C# code can only be used in stored procs).

To sum it up: if your DAL code is already running outside SqlServer 2000, it will be running outside Yukon as well.


  • I think the confusion comes from not understanding that the CLR running in Yukon/SQL Server 2005 is really, more or less, a replacement for extended stored procedures. Previously, we had the difficult task of getting the memory, threading, security, and many other issues coded correctly using C++ for extended stored procedures, and it was very, very easy to get it wrong. Assemblies hosted and used in Yukon will move extended stored procedures to the next level.

  • Good remark, Robert, I also think it's more or less a replacement for extended stored procedures.

    (left alone the custom aggregates, types and functions, which can be interesting).

  • Excellent description of the "problem".

Comments have been disabled for this content.