email article printer friendly

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

February 2005

Note: This is a transcript of an interview conducted at VSLive! San Francisco.

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.