You Couldn't Before, But Now Yukon...

(groan)

I'm away this week in the south of France attending an internal briefing on Yukon
/ CLR integration prior to the PDC. Whilst the tools themselves have still got a little
way to go before they're mature enough for production use, I've picked up a lot of
things that are not covered in the current documentation.

One particular feature I've been experimenting with is user-defined types (UDTs),
which allow you to create a custom type in C# that can then be used from within Yukon
- as a column type, a function return value, a stored procedure parameter, a variable
etc. There are some great potential uses for this - a few that sprang to mind include:

- A Currency type that handles both units (dollars, euros, pounds) and the value.

A *PostalCode* type that could do smart things like validation and even  
generate part of an address automatically using MapPoint(similarly, a *TelephoneNo* type).  
  • Many custom structures such as complex numbers, grid co-ordinates, and so on.

What really makes this feature work for me is that a DataSet could retrieve UDT values
out of the database, and the same Currency class used in the database could
be used in an application's business logic to manipulate it. This way, you always
deal with the object in the same way, using the same methods whether you're using
T-SQL or C#. In your database you can write:

         SELECT unitSKU, quantity, price::ToString() FROM Orders
    

In your code you can write:

         Label1.Text = price.ToString();
    

It's the same either way. You can even do things like operator overloading to ease
usage of the class in C# and attribute that same function to make it more accessible
from T-SQL. For instance:

         [SqlFunc("AddCurrency")] 
        public static override operator +(Currency c1, Currency c2) 
        { 
           // do stuff 
        } 
    

Lots more to say about Yukon - I'll start saving up some stuff to post during the
PDC.

Now off to file some bugs...