"My particular interest for the past couple of years has been to really think deeply about the big impedance mismatch we have between programming languages, C# in particular, and the database world, like SQL—or, for that matter, the XML world, like XQuery and those languages that exist there," Hejlsberg told Microsoft Watch Editor Mary Jo Foley and eWEEK Senior Editor Darryl K. Taft during the recent Microsoft Tech Ed conference.

"…When you're learning to program in C#, you're actually not just learning to program in C#. You're also learning SQL," he said. "Interestingly, we've come to accept that that's just how it is. But it doesn't necessarily have to be that way. The two worlds are actually surprisingly unintegrated."

Microsoft is looking to make progress to fix that the gap between the two worlds, both on the tools side and on the language side, where we'll see the "Whidbey" release arm programmers with much more code sharing.

Read more here about SQL Server 2005's incredibly cool CLR integration.

So what are DBAs afraid of? A typical scenario is that programmers will write for a development server. The application seems to work well on that setup, so developers move the code over to the production server. Performance takes a nosedive, and it becomes the DBA's responsibility to fix it, according to Kline.

"[DBAs will] look at code in there and say, 'You're using a cursor that consumes all sorts of resources it shouldn't have to, so let's change to an alternative [string] that works better," he said. "Now, the DBA traces to a CLR procedure, and when he opens it he doesn't know C#. It's code he doesn't know how to fix, but he's responsible for it."

Thus, many DBAs are at this point deploying a head-in-the-sand strategy to the impending CLR integration, Kline said, as few actively seek to acquire .Net or C# coding skills. "A lot of DBAs are saying, 'I'll be responsible for that when I know how to use it; when I'm familiar with it,'" he said.

Much of the problem has to do with the fact that .Net is just too hard, Dobson said. "Most IT pro people—I'm talking about the DBAs—did not embrace .Net" when it first came out in 2001, he said.

Dobson conjectured that this may be the reason for Microsoft to opt for turning the integrated CLR off by default when it ships the final SQL Server 2005 database. "Many DBAs have expressed concern about this CLR code hanging around their SQL Server databases," he said.

Between .Net being tougher to use than Visual Basic and having the integrated CLR shipped off by default, Dobson predicts that all this integration will be facing a languid adoption rate. "That combination of 'off by default' and concern by DBAs suggests to me that the integrated CLR will get off to a slow start," he said.

Next Page: Will adoption of the integrated CLR in the SQL Server world be hampered?