OK, so I'm going to do it again... I'm going back on .NET Rocks with Carl and Richard. We're going to try to stay focused and focus on SQL Server - 2000 and 2005. I'm looking forward to chatting about events, conferences and ways to improve performance/availability! I'm also excited to chat more with Toy Boy (Richard) regarding my latest geeky demo configuration involving SQL Server 2005 partitioned tables and a USB hub........

Here's where you'll be able to get all of the information needed to hear the show LIVE as well as chat with other listeners during the show: http://www.franklins.net/calldotnetrocks/

If you're interested in hearing the first show:
Here's the link on Franklins.net: http://www.dotnetrocks.com/default.aspx?showID=75
Here's the direct link for download from msdn: http://www.microsoft.com/downloads/details.aspx?FamilyId=18D23441-A24E-4BA3-8594-D29CD4D32979&displaylang=en
Here's the full list of DNR shows on msdn: http://msdn.microsoft.com/dotnetrocks/Default.aspx.

Thanks for listening!
kt

For the past couple of years, the early betas of SQL Server 2005 were very limited and even the events were somewhat limited - limited primarily to large customers under NDA, MVPs, RDs, and very dedicated SQL Server specialists. So far, only the SQL Express 2005 Edition made it on microsoft.com for download (click here if you're interested in SQL Express and the SQL Express Manager downloads)...

SQL Server Beta 2 and soon SQL Server Beta 3 have had slightly wider distribution, even being handed out to SQL Server conference attendees (such as at now PAST SQL Connections conference in Orlando), etc. but in most cases you need to have your own clean machine to install on and play with and you really need to have a completely spare machine as you don't want to impact any of your production and/or otherwise critical applications. For some, this meant not installing it at all.

If you're still waiting to get your hands on it, you have a new option! The SQL team has created a virtual lab environment.

Below is the promotional blurb I received. And, I decided to check it out for a second. When you click you'll need to install an ActiveX control, register and then login. Once logged in, you'll select your lab environment and then they will “build it”. Once selected, you'll have 90 minutes to complete the lab (and you can only enter one lab at a time) and you can download/print your lab manual (pdf format) to help you along. The feel is very similar to using Virtual PC and the build that was used in the labs I entered - was the December CTP of SQL Server (IDW 11). The current beta on Beta Place (for SQL Server 2005 Beta Subscribers is the February CTP which is IDW 13). Performance in my quick look around (of menu items, SSMS, etc.) seemed pretty good but I also have a decent internet connection. I started this process but didn't actually complete a lab yet... it's certainly worth checking out! Now you don't even need to install it yourself, you can use a Virtual Lab environment. If you do check it out - good or bad - let me know!

*************************************************

Are you ready to experience SQL Server 2005?

Announcing the launch of the SQL Server 2005 Virtual Hands on labs. In these labs, you will get to experience many of the new features in SQL Server 2005 including CLR integration, XML support and deep business intelligence integration.

Just follow the link and experience SQL Server 2005 for yourself!

Registration link:
http://msdn.demoservers.com/login.aspx?group=sql2005

*************************************************

When I first heard about "stored procedures being written in C#, VB.Net, ... etc." I remember thinking; Is Transact-SQL dead? Am I out of a job? What does this mean for me and for DBAs in general? Luckily, I learned quickly that not only is Transact-SQL not dead but it's got some significant improvements that might make code written in client applications A LOT easier - for example:
    1.      New syntax to traverse hierarchical/recursive relationships,
    2.      Extended XML integration,
    3.      Much improved error handling,
    4.      Easier in-database pivoting of data

I was worried that the CLR would cause problems for the stability of the database, acting like badly written extended stored procedures which can leak memory, crashing the server or even worse, potentially become a vector for worms and viruses. However as I learned more about the technology, I think that Microsoft has put in the work to give the DBA control over this technology. SQL Server controls the memory used by the CLR, there is a fully integrated security model and the DBA has control over what the CLR code can do and can even turn off the CLR completely on systems that will not use it. In fact, I also learned that the SQLCLR was going to be "off by default" as well. And, for me, as well as many DBAs, I think these points have squashed many of our fears. But then I almost felt like I was missing something? If things didn't need to change then why are they changing?

So, then I just wanted to know more about why the extension was being made to begin with and when and why it might be useful. From considering that point alone came the most important thing I've learned about SQL Server 2005; there are many new ways of doing things: Transact-SQL; SQLCLR; XML; Full-Text; Integration Services; Analysis Services; and all of them have different benefits and implementation effects. DBAs need to learn when to choose each of the technologies and even more importantly when their use is not appropriate, even when they're not an expert in all of them (and I truly think it will be a challenge to be an expert in every area of SQL Server 2005).

SQL Server 2005's feature set has been expanded such that C# or VB.NET can natively run in the server. This gives you immediate access to the power of the .NET Framework and helps to allow better integration with existing utility components and web services already in place. Some of the greatest benefits are that it allows you to place complex computations on the server - close to the data - without having to send large amounts of data to a separate application server. And all of this is done while SQL Server manages memory and resources ensuring a more balanced server system. So, my main recommendation for DBAs who are skeptical is to not worry about knowing everything about SQLCLR but instead focus on why it might be proposed and determine if SQLCLR is really the best way to handle it!

I’m still convinced that Transact-SQL wins when interacting with SQL Server using set-based SQL commands, but if you have a stored procedure with a cursor it may be a candidate for the CLR, if you have code that loads all the data in a table to perform special aggregations it may be a candidate for the CLR, as might your table valued functions (as the CLR does a really optimized job here). To sum up: the DBA has to get a grip of these new technologies and not let the development community overturn years of best practices in database system design – the same principles apply, there is just a richer toolset that, when used wisely, should improve performance and developer productivity.