SQL Server Yukon and .NET Programming Features

I went to see the talk about SQL Server Yukon and its .NET Programming Features given by Jose Blakeley and Eric Brown this morning.  There weren't as many demos as I would have liked to see, but there was no shortage of new things coming that they talked about.  My take is that its not just use any language to work with SQL, but also work with your data in any way you want.  That's right, you will be able to work with any data as either normal data (DataSet), objects (ObjectSpaces), or xml (XmlReader).  I'm not sure what all the implications or limitations are since I haven't gotten a copy of it myself (yet), but it makes sense.  Since .NET languages and constructs will be a native part of the database, its just a natural evolution to be able to natively expose objects.  Also, they will be adding an xml data-type to the database itself, so once again it just makes sense to expose any data as xml also.  My question is whether or not ObjectSpaces will be part of .NET itself, or part of SQL Server?  Why does it matter -- because I want to read and persist my objects totally independent of the database so my code will automatically work with Oracle and Access too!  I can do this now with Thona Consulting's EntityBroker, and others are also going down this path, like Andres Aguiar's DeKlarit, who I met this morning.

Here's a snapshot of the rest of the Yukon details.  You can write stored procedures and triggers in any .NET language, which is good for CPU intensive tasks, although maybe not the optimal choice for data intensive tasks.  You can extend sql data-type system in the sql engine itself, including aggregates..  Extended stored procedures will be able to run in-process when written with .NET languages.  Code access security will be a seamless part of sql security.  Xml will be a native data-type, including ability to query, update, and index xml.  You can also specify whether you want an xml data-type to be validated with an xsd.  There is also a new varchar(max) type that lets you work with unlimited size text, as well as new date and time types.  Sql will also finally get recursive or hierarchical queries, which has long been in Oracle.  You will be able to catch exceptions, like aborted transactions, in your stored procedures.  There will be support for triggers on ddl, queuing primitives, event notification, and service brokers.  The service broker stuff had more details that sounded good -- just think of it as asynchronous messaging in the database.  ADO.NET v2.0 will support multiple active resultsets on the same connection.  The ability to invalidate cached data when it changes that Scott Guthrie demoed will also be part of sql so its not just an ASP.NET addon.  Server-side cursor support will be added, asynchronous client access, built-in paging support, and much more.  Now if only the beta was available!

2 Comments

  • I dont want to nag too much, but most features look useless to me.





    I mean, server side cursors / paging - thats all stuff you better dont use anway due to the impact on the server. SP's are a portability issue :-(





    The object stuff could be interesting, if it is exposed through standard ADO - otherwise I will always prefer a O/R mapper. THough this mapper can become much more powerfull in regards to YUKON.





    Still, I dont think they can erally do it - no. Unless the objects inthe database are very "ui centered". Support databinding and all this. No, I dont think they can do it good enough. And an objectspaces like solution would be a solution on top of YUKON :-(

  • SQL Server has supported recursive stored procedures ever since 7.0. Perhaps I'm missing a nuance of the new feature.

Comments have been disabled for this content.