Soooooo, I've been thinking about the fact that the CLR is now embedded in SQL Server 2005 for use in stored procs, triggers, etc. It's also come out that the ADO.NET team is collapsing the proposed System.Data.SqlServer back into the System.Data.SqlClient namespace such that accessing data whether in a traditional 2-tier, or directly inside the SQL CLR itself, is identical. The "switch" that determines whether the data is processed inside or outside the database is a new connection string attribute simply named, "context connection".

Given the simple accessibility and portability of using the System.Data.SqlClient namespace from both within and outside of the SQL CLR, I have a simple question: Is there any utility in using ORM technologies from within the SQL CLR? My dream is real algorithmic reusability from within SQL...

I'm downloading the SQL Server 2005 Feb CTP drop right now. I'm curious as to how far the traditional development/OO paradigm extends into developing stored procs in .NET...

Jeff...

I too thought it would be easy to move the DAL into the sqlserver, but it turns out the unit which is written in C# and which is executable is a procedure. This means that there is no way you can have an appdomain inside the database in which your application runs. At least I don't know how and I haven't seen any evidence it will, if I read the sqlserver 2005 docs correctly.

My summary is here: http://weblogs.asp.net/fbouma/archive/2004/09/12/228419.aspx (from some time ago)

This is what you get when you 'host' the CLR and you choose the unit for which you host it badly: SqlServer didn't become a .NET appserver, it can run small units of .NET code, but that's it.

If you find different results in the latest CTP of sqlserver please let me know as it would be great to have the generated code and runtime libs inside the db (at least, be able to, I'm undecided yet if it is really great)

Hmmm... I wonder how that works as I assume the Base Class Library is available to the stored procedure - it must be, or at least part of it must be, as the System.Data.SqlClient namespace is available. I'll do some digging...

I wonder if Assembly.LoadFrom is available...

Jeff...