Several days ago I’ve downloaded new tool from Microsoft: Reporting Services Beta 2. Cause I’ve a experience with Crystal Reports 8.5 and CR.NET I’ve received a task to check its ability.
After downloading I’ve tried to install RS. It was easy task, but after reading readme file and, despite of fact that I’ve new computer with .NET Framework 1.1 just installed, “reinstalling” framework. Pay an attention to DTS service too: it must be running for proper RS work. You’ve to have a MS SQL Server2000 (or MSDE) running on machine. It’s good to have VS.NET also.
When I’ve installed new tool I’ve recognized that RS became a part of VS.NET tools: it’s fully integrated in it. Some play with samples showed me that reports looks pretty good. Components used for constructing reports are even more flexible than its CR equivalents (especially matrix which is CR cross-tab equivalent). Cause reports are defined in RDL (Report Definition Language) which is in fact a XML script, you can create reports without VS.NET using only Notepad.
Together with RS, web management tool is installed. It’s common point used for reports, roles and subscriptions (pushing reports) management. For a 1st look it’s cool piece of code.
Attempt of creating new report quickly cured me from good attitude. I’ve recognized that Reporting Services are in fact Access reporting tool ported to .NET and SQL Server2000 with incomplete functionality.
Report structure is the same like in Access: page header, body and page footed. Comparing it to CR reports it’s a huge step back due to lack of report header and report footed. Truly saying it’s possible to simulate lacking parts but it isn’t elegant solution. Another misfit is that existing parts cannot be divided into subparts (e.g. body a and body b) managed separately like in CR.
Another sad thing is limitation in variable using: global variables (e.g. PageNumber) can’t be used in body part and none data variable can’t be used in page header and page footer. It means that you cannot create report title in page header like “Detailed data for XXX customer”, where XXX is a name taken from database. This has such effect that majority of reports have only body part and rest of “parts” are simulated in body.
For C#ers I’ve very bad news: all expressions must be written in VBA – Access version of Visual Basic. Tool supporting expression writing is even poorer than its equivalent in Access cause in fact there’s no list of accessible functions, but only list of global variables and fields: you’ve to remember all functions and their syntax. If you want to use external functions in reports there’s no problem except that functions must be placed in assemblies written in VB.NET.
There are more inconsistencies for .NET environment coming from Access origin of RS. For example: textbox from RS is in fact label or subproperty Hidden where .NET controls have property Visible (with opposite work of course).
Reports are served in native format via management tool or special .NET control provided with RS. There’s some problem with rendering but they’re minors, e.g. unnecessary spaces or bad translating other than English letters in PDF exporter (reports can be exported to XLS, CVS, TIFF and MHT formats also).
Documentation is rather rich, but you must read it very carefully to remember what is where: there’s no search tool.
Nevertheless those misfits we’ve taken a decision of incorporating Reporting Services as reporting tool in future versions of our software. On such decision influenced following reasons:
* Now it’s separate tool, but it’ll be a part of Yukon server;
* Even as a separate tool it’ll (probably) be much cheaper than any commercial CR version;
* It’s still beta 2 version so we hope that all misfits will be corrected in final version;
* Due to previous Microsoft’s movements we hope that report’s internal programming will be available in C#.
Summarizing, Reporting Services stands very interesting alternative for commercial versions of Crystal Reports, mainly from financial aspect (I hope so). It looks much lighter that Crystal Enterprise also. Close coupling with SQL Server2000 and Yukon in near future allows expecting very efficient solution for reporting. Of course on current stage RS isn’t real counterpart for CR.NET, but as everyone can recognize designing and running reports in CR.NET isn’t painless process now. But there a question is born: if Microsoft is planning to develop such tool, will CR.NET be provided in future versions of Whidbey? Some doubts arise…