SQL 2005: CLR and downsize compatibility

I started in my spare time to play with the SQL 2005 bits. I also read some articles on CLR usage in SQL 2005.

But I can't find any clear answer on something somehow basic: compatibility.

I wonder how I can get CLR code in my SQL 2005 database running on Oracle, MySQL and ... SQL 2000 ?!?

What is the point of having SQL-92 as a standard if Microsoft breaks the rules and decide to go proprietary. Again don't misunderstand what I say.

What if you have a full set of CLR stored procedures, and you want to go to Oracle ? I am curious to know if Microsoft has in mind a set of tools to 'downgrade' or translate some of the CLR to standard procedures.

Don't forget, a lot of companies are still running with SQL Server 7 !

 

5 Comments

  • Here's one better:



    What if you have a bunch of regular stored procs in MS SQL Server 2000 and you want to go to Oracle?



    You're just as hosed because SQL standardization is a myth. Very few statements port between Oracle, MSSQL, DB2, etc. You usually have to write a compatibility/stub layer to handle all the minute differences.



    Also, Oracle has had Java, Perl, C++, and just about any other language you can imagine "built into" their engine for quite some time (though it's usually pretty sloppy and, like everything else in Oracle, slow and bloated).



    Going cross-database is either an excercise in parallel code paths or in least-common-denominator (which, with Oracle as an option, is a VERY, VERY low L.C.D.).



    I think it's time the world move on and stop trying to support all of Oracle's junk and slow migration and start forcing them to get into 1995 at least.

  • You focus on Oracle, but for me the problem is not only there, it's also SQL 7 and 2000 and MySql for example.

    And yes I was thinking about Crud functions. Unfortunatly we still have to write those ones in the real world. But if I write them in TSQL for example, why I should bother to rewrite them in CLR language if I want to keep a certain level of compatibility ?

    I am sure you can mention performance and .Net, but I am not sure making my database a .Net application has all the benefits. I am a full dedicated .Net guy, but I don't see the point to have some C# everywhere.

    Currently I can take an existing set of Crud procedures and migrate them to a new database quite easily, Oracle or MySQL, whatever.

  • You should still use TSQL for just about all the same stuff that you used in SQL 2000. The only exception is in SQL 2K's extended stored procs. Instead of extended stored procs, use the new CLR stuff, it is much more secure than the old way. Examples of uses of extened stored procs is stuff like accessing MSMQ, registry settings and other non-relational data stores.



    But then again, you can go crazy and instead of writing web services using ASP.Net, you can use SQL 2K5 to host your app instead of IIS.

  • The real 'Yukon' question remains: how much of the new stuff (CLR, real UDT, XML, T-SQL enhancements (top x comes in handy sometimes...) etc.) can an ordinary app use before it becomes incompatible? - You already know what the answer is :) - If you need to run on different DBs, you simply cannot use any of these features, even if the other DB is SQL 2000. But this break apparently has to happen from time to time and I appreciate the new functionality even though it locks me into Yukon. I still can decide when and how to use it!! :)

  • none had expressed your same doubt when Oracle embedded Java into its RDBMS engine. Why have we to think about it right now?

Comments have been disabled for this content.