Inside SQL Server 2005

Tom Rizzo, the director of product management for Microsoft SQL Server, talks about Reporting Services, SQL Server 2005, and more.

Jeff Hadfield: Tom Rizzo is the director of product management for Microsoft SQL Server, and we're going to talk a little bit about, well, SQL Server today.

Tom Rizzo: Glad to be here. I'm excited to be here and talk about SQL Server. Obviously, there's a lot of exciting stuff happening with SQL Server—both Reporting Services (they were released about a year ago, this is the one-year anniversary), as well as SQL Server 2005.

JH: Good. Well, let's talk a little bit about Reporting Services, since it's perhaps the subject we've talked about for fewer years than Yukon. So what's happened over the last year? You've released some new pieces to it. What have you seen in the last year for Reporting Services?

TR: There's been a great adoption of Reporting Services. As I said, it's our one-year anniversary. We released it January 27 of last year, so a little bit over a year ago. 135,000 downloads in a year. So that's pretty good for a version 1 product. Adoption has been through the roof. We see a lot of customers moving to Reporting Services. From a technology standpoint, it's integrated with Visual Studio, so if you're a Visual Studio developer, you could easily become a Reporting Services developer.

And we have some exciting new things coming out. We just released, probably a couple of months ago, something called Report Packs, which are pre-packaged Reporting Services—samples that allow you to do things like report off your Exchange Server, report off of things like Microsoft CRM, as well as other products that are out there. So a lot of customers said, "Give me some of these pre-canned things," and we delivered on that.

JH: Right. So you picked common scenarios and delivered on those.

TR: Common scenarios, yep. And there'll be a V2 of that, coming out in the next month to two months.

JH: Excellent. So what have been the sorts of things that have excited developers about Reporting Services, or what challenges have you run into in terms of adoption?

TR: What we've seen from a lot of developers is a lot of times, they have a lot of data, and they either generate that data through their applications or their end users generate that data using their apps, and they want simple reports or more complex reports off of that data. And so we made Reporting Services work seamlessly with Visual Studio so that you could just generate a report in there, deploy it to the server, and start working with it right out of the box.

The other big thing that we did is we built it on modern technologies. It's built on the .NET Framework. It's completely written in C#, it uses ASP.NET, and it's built using Web services, so if you want to programmatically write applications that leverage Reporting Services, it's a Web services interface, so that's helped with productivity and performance and making Reporting Services very easy to put into existing environments.

JH: I have to ask one more question about Reporting Services. It's something we didn't discuss ahead of time, so I apologize for that, but you've answered this question for me before, because I bring it up every time. How do you see Reporting Services fitting in with all of the third-party reporting services that are out there? There's a huge selection of reporting things, whether those are components or full packages or servers or other things that developers have been using or have used for years and years that are already in existence. Why Reporting Services? Why does it fit in? If I'm already using something, should I look at Reporting Services?

TR: Why didn't you just come out and ask me about Crystal and Reporting Services?

JH: Because I'm way too nice.

TR: You're too nice. Yeah, we get that question a lot. Or whether it's another reporting solution that's out there. But Crystal's one example. There are obviously other reporting solutions out there, or there's even the roll-your-own, which is customers fire up ASP.NET and they write their own reporting solution. So why should you pick Reporting Services over that, and how is Microsoft working with those vendors? I think that's how I'd rephrase your question.

JH: Much better phrased, yes.

TR: Okay, good. So the first thing is, we'll continue to work with any vendor that builds a reporting solution. We want to make sure that customers' investments continue forward in whatever solution they choose, and we want that to be on the Microsoft platform. And so we are working with Business Objects to continue to integrate that technology into Visual Studio as well as the overall Microsoft .NET solution.

But beyond that, we have a lot of customers who have found that Reporting Services is cheaper to own and operate than some other solutions and have migrated to that. We think that's because of productivity. As we talked about earlier, it's integrated into Visual Studio, has Web services native interfaces, is very extensible, and we continue to improve it. And the great thing is the price is right. It's included with a SQL Server license, so if you run it on the same server that's your SQL Server, guess how much you pay Microsoft?

JH: I'm guessing that would be nothing.

TR: Zero, zilch, nada.

JH: And how often can you say that anymore?

TR: How often can you say you actually value something you get for free? Well, I think Reporting Services is definitely one place where you can say that.

JH: That's bringing a tear to my eyes. We're talking about values of things. For the last 20 or 30 years it seems like, we've been talking about the imminent release of Yukon or SQL Server 2005. I think I'm only exaggerating by 25 years or so.

TR: Yeah, I've been on SQL Server now close to four years, and I'm still shipping Yukon every year, right? We are on track for getting it out, hopefully this summer, in 2005.

JH: So it will match the product name.

TR: Match the product to the year that's actually in the name, right. And you can see the progress we're making. SQL Server is actually pretty revolutionary with 2005. We've taken the best of .NET and integrated it into the server itself with the SQL CLR integration that we have. But you can see the progress that we're making. Beta 2 released last summer. We've been dropping what's called community technical previews every couple of months. We had one in October, we had one in December, we have one coming up in the next couple of weeks, probably in February or March.

So we're making continuous progress on the product, and the great thing about these community technical previews is that customers don't have to wait for these big betas. It's hard to absorb all the changes that come in the beta process, so the CTPs have been helping us, but the other thing too is that it gives us feedback that will help us complete the project in a much, much faster way.

JH: You've mentioned in passing the SQL CLR. Forgive my ignorance overall, but specifically in that area of the SQL CLR, but if I'm a dev and I'm used to doing a T-SQL report or other approaches, why do I care if there's a CLR?

TR: Yeah, there's a lot of confusion with SQL CLR, so let me try and set it straight. If you don't understand it, just ask me and I'll try to explain better, but I'll try to take a shot at it. So the first thing is, what we heard from a lot of developers is T-SQL is a great language; it's a great data access language. But when you try and do things that are not data access, things that are CPU-intensive—string manipulation, maybe some mathematical functions, integration with Web services, date manipulation—we try and do that inside of T-SQL, but the .NET Framework's a lot better than what we are in SQL Server in T-SQL.

We never built T-SQL to be a full-featured programming language. That's what the .NET technologies are. So that's why we did the SQL CLR: We wanted to make it so that you could build stored procedures, user-defined functions, aggregates, triggers, whatever, using the languages and the technologies that you're used to from .NET.

JH: Instead of having to learn the SQL syntax?

TR: You're still going to use T-SQL probably in your SQL syntax on the server, but the nice thing is it's ADO.NET on the server and ADO.NET in the mid tier, so if you're really good at VB or C# in the mid tier with ASP.NET or on the client with Windows Forms, moving that stuff to the server should be seamless for you when you move to the SQL CLR.

The other question that a lot of customers ask too, and developers ask, is, "Okay, how's performance, though?" And the great thing we did was we integrated in process the CLR, so it's not an out-of-process thing. We managed the memory from SQL Server both for managed code and the SQL Server native code that's running so that we know when to ask for more memory back for the CLR and that sort of stuff. And debugging—you can debug across languages from T-SQL to C# to VB and back to T-SQL. So it's very, very integrated and it should make it pretty easy for developers.

JH: It sounds like you're pretty excited about those. Are there any other things that you're excited about with your development background and your experience, or things that you've heard going through the CTP debate process that developers are particularly finding, to use a technical word here, nifty?

TR: Nifty. SQL CLR obviously is on that list. And just to touch on one thing with SQL CLR, we have a lot of developers who build extended stored procedures in SQL Server with C++. SQL CLR can replace those so that they're more secure than extended stored procedures. But beyond SQL CLR, one of the things that we've heard is the XML support. XML is one of those things that if you don't use it in a sentence, people don't think you're cool. So we've integrated in XML as a native data type. So just like you can create a column of type float or int or nvarchar inside of SQL Server, now you can create a column of type XML. You can store your XML data natively in there. You can index it using the XML indexing technology. You can query it using the new XQuery standard, which is new for a lot of people, but the way I like to think about it is XQuery is to XML as T-SQL is to SQL Server. It allows you to be very rich in the query language that you use against your XML documents.

And XML is just an exciting thing, and the key thing that developers have to remember: It's not one or the other; you can combine your relational data with your XML data because we support this idea of cross-domain queries where a relational query can have an XQuery embedded inside of it. So the two worlds don't have to be different.

JH: Great. Any other parting words you have to make sure that developers are getting themselves all warmed up for these supposed imminent rollouts?

TR: Yeah, I would definitely have developers not only take a look at SQL CLR and XML, but take a look at the native Web services support that we have inside of SQL Server. One of the feedback we heard is we had a release called SQL XML—1.0, 2.0, 3.0 is the latest incarnation of that with Service Pack 1, I believe—but one of the things we could do with SQL XML was that we could expose a stored procedure as a Web service or even T-SQL batches, so you could just send up a select statement or an insert statement to the server, but that required IIS in the mid tier. And one thing we heard from developers was, "I don't want to have to have IIS. I love it, but I love it for building Web apps, not having to use it for my SQL Server Web services. I want the server to natively expose itself at using the Web services technology."

And so that's what we've done inside SQL Server 2005. You create an end point in the server, you secure it using just standard Web-based authentication or Web services authentication using WS security, and then you can come in and call a stored procedure or call in any sort of T-SQL batch to that server. We use the HTTP.sys technology that ships in Windows Server 2003 or Windows XP SP2. It looks like you don't know what that is ? .

JH: No, I'm giving you the blank look.

TR: It's the kernel mode driver, the HTTP listener kernel mode driver that IIS also uses. But we use it inside of SQL for the Web services integration. And the reason we did Web services is a lot of people say, "Hey, should I use native ADO.NET, or should I use Web services?" And really, it's your choice. We built the Web services technologies for interoperability. You may be running on a Unix client or a Unix server and you need to talk to SQL Server. Well, you may not have a native driver on that platform, but you could use Web services to do that.

JH: As we've talked over the years, one of the uses that you have mentioned, especially in the enterprise for SQL Server, has been as a great data aggregator across platforms using the Web services capabilities and enhancing or enabling that further.

TR: Yeah, Web services takes it to the next step. The great thing is now you can access your data from any Web services client. One of the things we're doing inside of Microsoft is we're testing against obviously Visual Studio, but across non-Microsoft tools, so Borland's JBuilder or some open-source technologies. We want to make sure that our Web services and our WSDL format is available to those clients and works across a wide set of both development tools and application platforms. The other thing too is if you don't like our WSDL, guess what? It's replaceable. You can write some code, generate your own WSDL from our server, and be able to interoperate with SQL Server in that way.

JH: So you're not locked in there.

TR: You're not locked in. We're completely extensible. You don't like our WSDL, replace it.

JH: You can embrace and extend your WSDL.

TR: Embrace and extend, just like old IE, right? Embrace and extend.

JH: Great, thanks for your time today, Tom.

TR: All right. Thank you, Jeff.

comments powered by Disqus
Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.