In-Depth

Report Card: Microsoft's SQL Server 2000 Reporting Services

Users say they’re mostly satisfied with the six-month-old version 1.0 product—although almost all have a pet peeve or two they’d like Microsoft to fix

• By Stephen Swoyer
• 07/28/2004

July marks the six month anniversary of SQL Server 2000 Reporting Services, a first-of-its-kind enterprise reporting add-on for SQL Server Microsoft Corp. released in late January.

A surprising number of Reporting Services users were beta adopters of that product, but many more have since deployed the Reporting Services gold code (see http://www.esj.com/business_intelligence/article.asp?id=6832&t=y). We spoke with several of them as part of an effort to identify what works, and what still needs a bit of tinkering, in Microsoft’s enterprise reporting solution.

Most users say that their Reporting Services experiences have been largely trouble-free, especially now that Microsoft has released at least one service pack for that product (see http://info.101com.com/default.asp?id=8308). Nevertheless, several users are still dealing with problems that weren’t addressed by Microsoft’s service pack fix.

Take Dennis Parks, a contract IT manager with a manufacturer of tools and cutting instruments. Parks says that his employer experienced no end of problems installing Reporting Services on a domain controller. “[We] worked with [Microsoft] tech support on a problem, in which they did finally duplicate” the issue, he explains. Parks developed what he calls a “slight workaround,” but says that his employer has abandoned Reporting Services for now. “[We’re] waiting for a service pack which will hopefully fix the problem. Otherwise I'm creating reports manually with Visual Studio for users.”

Dave Bienstock, a systems specialist with mobile home manufacturer Fleetwood Enterprises Inc., has a more pragmatic perspective on Reporting Services 1.0. “We like it, but are looking forward to seeing improvements in SQL Reporting Services over the next year or two. I am glad it was developed."

Previously, Fleetwood used a reporting solution based on Microsoft’s Access database, Bienstock says. “We are using SQL Reporting Services as a means to migrate away from Microsoft Access-based reports and to reduce the bandwidth required to allow other departments and VPN users to view data through the SQL Report Manager front-end,” he explains.

One drawback of Reporting Services 1.0, says Bienstock, is that it doesn’t duplicate common Access features. “Access has more capabilities that make it hard to convert—like Pivot Tables with non-aggregate data in the cells.” Elsewhere, Bienstock says there are several things he’d like to see Microsoft deliver in the next version of that product. “I wish there were more tools to customize the report interface, besides the style sheets that do not have a GUI. One thing we've not been able to figure out is, based on the literature, [how to] find an Active X calendar control that will work or not be grayed out.”

Nevertheless, Bienstock gives Reporting Services an enthusiastic thumbs-up: “We have … found lots of new items that allow us to do queries based on wildcards, hide columns, do sub-reports, have decent security on reports or report folders, drill-down, and most importantly, use .NET controls.” Steve Swope, a technical manager with The Reynolds & Reynolds Co., says that his company is implementing Reporting Services as part of a .NET rewrite of one of its internal data entry applications. Like fellow Reporting Services convert Bienstock, Swope thinks that the version 1.0 product is not without its pluses and minuses. On the plus side, he says, Reporting Services is multi-threaded, features good printability, is relatively easy to develop for, supports a variety of export definitions, and is easy to deploy. Reports can also be cached in memory, says Swope, which helps to speed retrieval.

Negatives include the fact that reports are directly coupled to data sources, that selection parameters are, in turn, coupled to reports, and that both documentation and the extant example pool are sparse, according to Swope.

Overall, most Reporting Services adopters seem to approach that product with a mindset that’s characteristic of users of Microsoft’s version 1.0 software, regardless of platform: They expect that it will get better. “I really look forward to seeing the next version when Yukon comes out. This product shows a lot of promise,” says Peter Schott, a DBA with Drive Financial Services.

Schott says that Drive Financial implemented Reporting Services to more quickly and effectively disseminate Excel reports to users. In this respect, he says, Reporting Services has already gotten better—thanks to SP1. “The latest service pack, [reduced] the size of the Excel files and [allowed] them to be opened on older versions of Excel,” he concludes.