It's no secret that one of the most important features of SQL Server 2005 is the integration of the Common Language Runtime (CLR) with the database. However, IBM's recent release of DB2 UDB 8.2, codenamed Stinger, surprised a lot of people and stole SQL Server 2005's thunder by supporting database-object creation through .NET. Although IBM got CLR support out the door first, don't make the mistake of thinking that the CLR support DB2 UDB 8.2 offers is the same as the CLR support SQL Server 2005 will provide. There are some profound differences in the way each product implements support for the .NET CLR.

First, the two products support different types of database objects. DB2 UDB 8.2 supports the creation of only stored procedures and functions and integrates the creation only of stored procedures (not other object types) into the Visual Studio 2003 development environment. DB2 UDB 8.2 currently doesn't provide integration with Visual Studio 2005, although Visual Studio 2005 is still in beta, so this could change. In contrast, SQL Server 2005 supports the creation through .NET of a full range of database objects: stored procedures, functions, triggers, and so on. Visual Studio 2005 includes templates for all of these objects. It's worth noting that you don't absolutely need Visual Studio to use the .NET features of either product. Their respective Visual Studio integration pieces enrich the development process, but you can also develop .NET database objects for either platform just by using the .NET Framework Software Development Kit (SDK).

Additionally, DB2 UDB and SQL Server 2005 interact with the CLR in very different ways. With DB2 UDB 8.2, the CLR is an external implementation, and the database executes calls to the CLR exactly as an application might use the .NET Framework. In this scenario, the .NET Framework manages its own resources independently of the database. SQL Server 2005, however, hosts the CLR in-process, giving much tighter integration. SQL Server 2005's in-process hosting yields several important advantages. First, it lets SQL Server control CLR execution, putting essential functions such as memory management, garbage collection, and threading under the control of the SQL Server database engine rather than letting the CLR manage them independently. The database engine knows more about the system requirements and can manage memory and threads better than the CLR can. In-process hosting will provide better performance and scalability.

The two implementations also offer big differences in the development experience. DB2 UDB supports creation and deployment of assemblies, but it stops there. SQL Server 2005's integration with Visual Studio 2005 supports seamless debugging of those objects after their creation and deployment. Visual Studio 2005 automatically generates a T-SQL wrapper that you can use for testing .NET database objects and fully supports debugging of .NET database objects with all the capabilities you'd expect to have in client-side code. With SQL Server 2005, you can set breakpoints and seamlessly step between .NET code and T-SQL code.

Although both DB2 UDB 8.2 and SQL Server support the creation of .NET database objects, the two platforms are integrated with the .NET Framework and the Visual Studio development environment in profoundly different ways. IBM's DB2 UDB 8.2 may have gotten .NET integration first, but Microsoft and SQL Server 2005 got it right.

End of Article


You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

This is a stupid article.

SQL Server 2005 isn't shipping, and the hosting APIs that it relies upon for its 'better' CLR integration are in Whidbey, which also hasn't shipped yet.

So... DB2's implementation is the only one available today, but somehow it's worth because Microsoft's teams got to share the API design before the release. (Assuming that it does release someday)

I use SQL Server 2005 every day in beta, but this is a soporific article peddling promises instead of real results. [and, of course if DB2 isn't shipping yet then my bad. I don't even use DB2 but this article is clearly biased.]

Anonymous User- January 25, 2005

The Shakespearean title twist is pretty much the best part of this article. The article does come across as bias but then all you have to do is look at the site your on. So DB2 is a major threat to SQL server 2005?

I thought it was just another database to collect data. What about data integration between databases. I keep hearing about how well SQL Server 2005 will do that. is it true?

ttvillella- January 27, 2005

Article Rating 1 out of 5

Mr Otey's comments are just too bias to take -- but then again you all realize MS paid him to publish a legnthier paper on their Web site -- correct? And if the $$ did't change hands -- you will understand how this happens. The sad part of all this is I enjoy Mr. Otey's stuff (usually) -- usually they aren't so bias.

Anonymous User- January 27, 2005

Article Rating 1 out of 5

The CLR is a poor performance dog just like the java dog. By embracing these idiotic runtime compilers, MS, IBM and Oracle are declaring the Emperor's clothes are beautiful. But in fact, the nitwit is naked. If Otey wanted to be helpful to the community, he would acknowledge the native CLR weakness, and condemn all the majors for sticking this on us.

give me a clean server instead of the dog. Hopefully, I can retire before 2005 takes over for 2000 and v.7.

Anonymous User- January 29, 2005

Article Rating 1 out of 5

I always get a good laugh out of the Microsoft people(sheep) that think that Microsoft is the only thing right in the world.

Look at this quote: "IBM's DB2 UDB 8.2 may have gotten .NET integration first, but Microsoft and SQL Server 2005 got it right."

The problem is that Microsoft hasn't "got" anything. This product doesn't exist yet (aside from Beta). IBM's product is real and today.

Hey Microsoft, how about fixing the problems in the Current products before forcing all the "better", non-existant stuff on us.

Anonymous User- February 01, 2005

Article Rating 1 out of 5

I agree that this article is completely and 100% bias. The author probably has never used DB2 in a real world Big Iron environment where IBM GOT it right. With all that's said SQL Server still continues to be the little brother to Oracle and DB2. Just look at the TPC results lately. An IF Microsoft ever does ship the product that was suppossed to come out about two years ago, then may the author could right this article. Until then let me tell the author something. Microsoft Hasn't Gotten Anything Right... They can't even keep their timeframe. Now Exchange Server is being scaled way back. It makes me laush how Microsoft seems to be on the defensive these days.

Anonymous User- February 03, 2005

If SQL Mag has any respect for itself, this writer should be let go. He clearly can not give an hnoest opinion. I feel like I was reading a Democrats paper on a Republicans plan for Social Security. Clearly biased, Clearly an agenda, Clearly writing to satisfy Redmond and not giving good impartial reviews to loyal readers.

By the Mr. Otey, can you tell me when the whole DB2 database environments around the world were brought down by something as simple as the slammer?

Anonymous User- February 03, 2005

This article is pure science-fiction. Of the worst quality. Mr. Otey succeeds to compare the incomparable: DB2 an existing, real product, that delivers real performance, with a ghost named SQL Server 2005, a non-existing product, that delivers nothing but promises and marketing literature.

A ridiculous piece of writing, a total waste of time and an insult to the practitioner.

Anonymous User- February 04, 2005

Article Rating 1 out of 5

Even if this is a SQL Server focused magazine, I expect articles to be more than a advertisement of Microsoft products. I have been using SQL Server for a long time, but the truth is that DB2 UDB has been shipped, whereas Sql Server 2005 is in Beta and still has to show what will its performance be.

Anonymous User- February 04, 2005

Article Rating 1 out of 5

Frankly I don't get what the anonymous ******** is about here. Sounds like somebody else has a vested agenda to me.

On the "its only beta, its only beta" chatter: I wouldn't be one bit "shocked" if there more total installed instances of the beta product than there are production versions of DB/2 Stinger. I'd say that makes it pretty darned real. An TPC benchmarks? Are you kidding me? Go look at the TPC-W where it really matters: Price to Perf. Where's DB/2 on that list? *Hint*: there's a reason that business *choose* SQL Server: It's called making financial sense!

But let's look at some things that the article has to say...

Paragraph #1: Michael's point here is pretty clear: DB/2 had CLR support before SQL Server did but SQL Server 2005 does things *different* than DB/2 does. No more, no less. Advantage: push, I think. Being first doesn't mean being best.

Paragraph #2 main points: DB/2 only supports invocation of the runtime from stored procedures; SQL Server supports that and more like functions, type, aggregators and triggers. Advantage SQL Server. DB/2 supports the current version of Visual Studio.NET, where as if you need a GUI for SQL Server, you really want to use the also-beta Studio 2005. I'd call that an slight advantage for DB/2, at least today. Regardless, you can use SDK and any tool you like -- including WebSphere, Eclipse and SharpDevelop -- to do your coding.

Paragraph #3 main point: DB/2 calls the CLR out-of-process, SQL Server calls it in-process. The advantages of the in-proc call are obvious to anybody that's ever thought about it. Funny that for all the complaints registered here, you've got nothing to say about the that. Advantage SQL Server.

Paragraph #4 main point is that while DB/2 supports the invocation of the CLR, it stops there. No tracing, no visual debugging. SQL Server supports those things and you'd better believe they're important to both developers and DBAs. Huge advantage SQL Server.

Paragraph #5 main point: Michael feels Microsoft made their support for *better* than DB/2 did theirs in a number of ways. Pretty hard to argue against that. For all your complaining, you didn't even bother to try to either. Can you?

Finally, just because you don't like the message, trying to kill the messenger strikes me as sign of just how biased you really are. Had you done a little bit of research, you could have easily found out that TEAC has such extensive experience working with the IBM platform (since at least 1996) that the actually ship products that make it easier to work with. You'd also find out that he was writing great books about programming (ISBN 0962874337) with the AS/400 platform as far back as 1993.

And you?

Sounds more like you've got an Axe to grind than valid criticism of the article or the product.

Kent Tegels/www.tegels.org

Anonymous User- February 05, 2005

Article Rating 4 out of 5