The Old Joel on Software Forum: Part 3 (of 5) - Yukon

Yukon - Disappointment ?

Perhaps I was naive, but I was really hoping that the .NET integration with SQL Server in Yukon would allow me to write Stored Procedures and mix SQL with C# somehow.

It seems, at first glance, that this will not be possible and that we will be limited to effectively declaring external functions which may be written in C#, etc. Although useful, I hope it won't end up being as clumsy as manipulating COM objects via sp_OACreate, etc.

I hope I've completely missed the point here guys. Any comments ?

Steve Jones (UK)
Wednesday, January 7, 2004

"mix SQL with C# somehow"

That would be just like Visual FoxPro code, which in turn is nearly the same as T-SQL (with SCANs and WHILEs etc) - So if that is what you want to do, I think you should just stick to T-SQL.

My thoughts on what this will allow us to achieve is things like call a WebService in a storedproc (although obviously that would have a huge impact on performance), and probably about a billion other completely stupid things that your customers might want you to do on the DB server despite any performance hit. But it may also allow us to do other useful things like log events to the windows event log or load COM components in a stored proc (again I have no idea why you would want to do any of this, just that you can)

Chris Ormerod
Wednesday, January 7, 2004

Originally it struck me as a similar level of integration as the desktop and folders and being able to apply namespaces to folders and so expose the application's data to users as if it were just files and folders.

But it never really took off, its too complex to manage for large data sets and it hides the application so thoroughly that the brand disappears.

It may be that having a SQL filesystem will prod that into life again but apart from replacing the vile Indexing of files I'm sure most of the benefits will be entirely hidden.

Simon Lucy
Wednesday, January 7, 2004

What I really wanted was a richer language to work with, rather than Transact SQL. I know it has conditionals and loops, so you can do anything you need, its just that sometimes SP code looks very long-winded, especially the error handling code.

Basically, I'd settle for some kind of sensible error handling scheme, which didn't require code to check for possible errors after every statement. That would reduce the size of most SPs by 50%.

Steve Jones (UK)
Wednesday, January 7, 2004

Wait a second, am I wrong? I wrote my comment based on the assumption that Yukon is the next SQL Server version, not the WinFS that is in Longhorn (which is what I think Simon is talking about)

Do we need some clarification here?

Chris Ormerod
Wednesday, January 7, 2004

I was referring to SQL Server as a database development platform, ignoring the "WinFS is really a database" stuff.

Steve Jones (UK)
Wednesday, January 7, 2004

No, I need some sleep.

Longhorn arrived the same time as Yukon and I conflated them.

mea culpa, mea maxima culpa.

Simon Lucy
Wednesday, January 7, 2004

Sadly true Steve, I too was hoping for something better as well. However it did look useful and I do have a need for it (due to a bug in SQL2K)
When I saw a copy a while ago the comment from the demonstrator was that it would be worth using from a speed point of view once you wanted to do more than 4 calculations.
Personally I reckon the MK II version will be much better. Although perhaps with some of the Longhorn stuff, the CLR integration is being reviewed.

Peter Ibbotson
Wednesday, January 7, 2004

Yeah, it would have been a "must have" upgrade for me, but now its become a "whatever" upgrade (c.f. the "K" thread, about the last database).

Hopefully it'll be more interesting as we get closer to the actual ship date.

Steve Jones (UK)
Wednesday, January 7, 2004

Perhaps Philo can add some comments to this (or perhaps not).

So far the only stuff I've seen has been the demo done by Euan Garden at Microsoft(UK) back in june (Nice bloke)

I was hoping the PDC preview disks for MSDN subs had Yukon on but it was Longhorn and Whidbey. I wonder if this says something about the state of readiness of Yukon?

Peter Ibbotson
Wednesday, January 7, 2004

Of the three technologies, only Yukon is in beta (and it's farther along for normal beta testers than what the PDC bits were that got given away).

However, because Yukon has a dependency on Whidbey, they will almost assuredly be released together, even if one is done and ready far before the other.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, January 7, 2004

Well, Steve's right and wrong.

You can't intermix C# and T-SQL inline, but a Yukon SP will be like an assembly with an open connection to the database, so you can execute SQL, retrieve results, and act on them.

A fairly in-depth overview is at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/html/sql_ovyukonnetprogfeatures.asp

Including some example code.

I hope this helps, and lessens the disappointment. :-)

Philo

Philo
Wednesday, January 7, 2004

Thanks Philo.

Although it is certainly interesting/useful, it doesn't mention any possible enhancements to the unlerlying Transact-SQL language.

It seems strange to me looking back over 20 years in IT that I spend roughly half my development time using Visual Studio 2003 and ASP.NET in C#, and half writing T-SQL SPs for SQL Server 2000.

The contrast between the super hi-tech former and the barely adequate latter is incedible. The language/syntax in T-SQL is not much more sophisticated that the Z80A assembly I used to work on 20 years ago, when I started in this IT game.

If only SQL Server was "open" (in the sense of having suitable APIs, not Open Source), then some bright spark could perhaps create a better stored procedure execution engine.

Perhaps there is some technical reason why it can't be done, but I really hoped that we'd see stored procedures written in C#, not just UDFs on steriods as we seem to have got. Don't get me wrong, I'm sure it'll be useful, it just doesn't tick everything in my wishlist.

At the end of the day, as mentioned earlier, I would have settled for some form of structured exception handling, rather than having to check for errors after every statement. What was the codename for the SQL Server after Yukon again ? :0)

Steve Jones (UK)
Friday, January 9, 2004

Oops, "unlerlying" is obviously "underlying".

Steve Jones (UK)
Friday, January 9, 2004

Interesting observations, Steve. I hadn't thought of it before, but I really don't have a problem with T-SQL. With some minor limitations it does what I need when I need it.

I'm wondering if my perspective is one borne of simply accepting the limitations of the tool, or if we have some seriously different dev experience. :-)

Philo

Philo
Saturday, January 10, 2004

Philo,

It certainly does the job, but I think it could be a lot better (see comparison between VS.NET 2003 doing C# and T-SQL, mentioned above).

I have been involved in a number of systems where the "business rules" have been written in T-SQL stored procedures. For non-trivial cases, say 1000+ lines of code, T-SQL soon shows itself to be sub-optimal.

I remember using Oracle SPs years ago and you can do things like declare constants that are shared across the SPs in a Package (group of SPs). Constants are hard to do in T-SQL so you end up with work-arounds.

In general, I agree with the "if it ain't bkore, don't fix it" crowd, but given the enormous amount of effort expended by MS to go from 6.5 to Yukon, I submit that (say) 1% of that effort could have been devoted to improving T-SQL.

In conclusion, T-SQL does the job and you can express pretty much any algorithm in it (even recursion if you keep an eye on the nesting level), it just doesn't seem very 21st-century. I was deluding myself with the Yukon .NET integration, hoping it was something it isn't.

Steve Jones (UK)
Monday, January 12, 2004