You want to start working with Visual Studio 2005 Beta 2 or SQL Server 2005 April CTP (Community Technology Preview)?
You need training on Whidbey Beta 2 or Yukon April CTP?
You want to run VSTS Beta 2 to get started with those awesome new tools?
Well, if you’re living in Europe, Middle East or Africa, we will ship the bits to you. Except if you are living in Germany, you will actually get the DVD’s for free. This is part of the Beta Experience program.
So even those people who have to deal with low bandwidths and those that don’t enjoy the early access MSDN subscribers do, will be able to enjoy working with VS 2005 Beta 2 and SQL Server 2005 Beta 2.
Check out the link below, register and you’ll get the bits and a 6 weekly newsletter with more technical information. Not a bad deal is you ask me. (I’m sure you won’t ask.)
www.microsoft.com/betaexperience
There will be links on local Microsoft sites too.
Enjoy
Just talked with Shaun Hayward. Someone who onviously very passionate about coding. A (long) while ago he asked me for my opinion on Operator Overloading for User Defined types in SQL Server 2005.
Shaun
Good day I came across your blog while looking for Yukon UDT info. I've found that I can't deploy an assembly if any of my UDT's have overloaded the = operator. I think this is strange since the SQL code would make a lot of sense: SELECT MyTable.PlaceName FROM MyTable WHERE MyTable.GPSCoordinateField='49.25,17.36' Just wondering if you have any thoughts. - Shaun
Me
I just found this email underneath whole lot of others. I’m really sorry for the really late reply. What you suggest would definitely make the code more esthetic. I’m not sure whether there are any other benefits since all can be achieved by writing a method on the UDT or by actually instantiating a second object and comparing them. In any case I can understand why the product chose not to invest in Operator Overloading. Also, Operator Overloading does seem to be more challenging in an environment where you would use .NET code to overload a SQL operator. The ‘=’ in this statement is still a SQL Operator, agree?
I just found this email underneath whole lot of others. I’m really sorry for the really late reply.
What you suggest would definitely make the code more esthetic. I’m not sure whether there are any other benefits since all can be achieved by writing a method on the UDT or by actually instantiating a second object and comparing them. In any case I can understand why the product chose not to invest in Operator Overloading.
Also, Operator Overloading does seem to be more challenging in an environment where you would use .NET code to overload a SQL operator. The ‘=’ in this statement is still a SQL Operator, agree?
Shaun :-)
Hi Hans Thanks for the reply. We could get into a big philosophical debate about whether or not the “=” is really a SQL operator. I mean, what is an operator but a shortcut for calling a function? I could be wrong, but my guess is that .NET compiles = in VB.NET to one of those funky “op_” methods. Most operators seem to do this. After all, everything (property, method, constructor, operator, or event) is just a method call in disguise. For that matter, .NET in general should be able to support custom operator defining. But I digress… The problem is that SQL Server has certain expectations for its operators. How can you ensure that hack developers actually do the right thing with an operator? What if they toss code into an endless loop? What if they call unmanaged code and throw an IPF or GPF? So I fully appreciate why SQL Server cannot support them at this time. I suspect, however, that future incarnations will come up with ways to handle all of these problems and an operator will be neither a .NET operator nor a SQL Operator. .NET is blurring these lines, much to the praise of developers – myself included. For now, there is a work around by my philosophy of idealism remains much the same :-) Once we have full operator control in SQL Server next then my next task shall be to elect an honest politician!
Hi Hans
Thanks for the reply.
We could get into a big philosophical debate about whether or not the “=” is really a SQL operator. I mean, what is an operator but a shortcut for calling a function? I could be wrong, but my guess is that .NET compiles = in VB.NET to one of those funky “op_” methods. Most operators seem to do this.
After all, everything (property, method, constructor, operator, or event) is just a method call in disguise. For that matter, .NET in general should be able to support custom operator defining. But I digress…
The problem is that SQL Server has certain expectations for its operators. How can you ensure that hack developers actually do the right thing with an operator? What if they toss code into an endless loop? What if they call unmanaged code and throw an IPF or GPF?
So I fully appreciate why SQL Server cannot support them at this time. I suspect, however, that future incarnations will come up with ways to handle all of these problems and an operator will be neither a .NET operator nor a SQL Operator. .NET is blurring these lines, much to the praise of developers – myself included.
For now, there is a work around by my philosophy of idealism remains much the same :-)
Once we have full operator control in SQL Server next then my next task shall be to elect an honest politician!
Surely, by now you have reviewed all sessions we've got lined up for TechEd Europe at our 80% list complete point. (http://www.mseventseurope.com/TechEd/05/Pre/Content/sessionsearch.aspx)
Now let's say you really want to see another topic covered but you know that we closed the call for papers site on the 11th of March. What can you do?
Like last year we are again having a room where we don't schedule the sessions but 'the community' does.
For developer related topics 'the community' is INETA and the enthusiast managing the session list for that room is Damir Tomicic. He is looking forward to getting your ideas as you can read here: http://tomicic.de/PermaLink.aspx?guid=5566ef11-3237-446d-8c90-08673ef50d41
With these, I won't have to travel around anymore talking about Yukon :-) It's a win win!
Discover how Microsoft SQL Server 2005 offers database developers the optimal combination of a tightly integrated development and data management platform. The rich and flexible programming environment in SQL Server 2005 allows you to leverage your existing skills and utilize familiar tools to build robust, secure, scalable applications.
Register today to learn how the integration of the .NET Framework in SQL Server 2005 provides several major benefits, such as an enhanced programming model, enhanced safety and security, user defined types and aggregates, and a common development environment that integrates database development into the Microsoft Visual Studio 2005 development environment. In this series, we cover:
Register for the SQL Server 2005 webcast series to learn more.
Bonus: Attend a webcast in this MSDN series and complete an evaluation to receive the most current version of SQL Server 2005 Beta software on CD. Attend at least three MSDN webcasts in this SQL Server 2005 webcast series and submit evaluations and you will receive a SQL Server 2005 T-shirt*. And by attending a live webcast in this series and submitting an evaluation, you will qualify to win a Portable Media Center (official rules) pre-loaded with our best webcasts!
Registration link:
http://www.microsoft.com/events/series/msdnsqlserver2005.mspx