One challenge that we have at my place of employment is figuring out the best way to centralize our Reporting Services code.  We have many customers and each customer has their own database but most of the reports that we develop for customers are the same.  So what we have done is to create a separate folder called DOLM (Deploy Once Link Many).  What we do within this folder is locate our base reports.  From this folder we create and push out linked reports to customer's database folders. 

What is the great part about this technique is that we maintain one set of centralized reports and push out these reports to the customers folders.  Withing the customer folder the report name can be changed and the default parameters can be changed depending on the customer. 

So, if you haven't even considered using linked reports I recommend that you definitely look into them!

Another great advantage to RDLs is the ability to perform an Explorer search on the file for a key word or any text for that matter. This simply cannot be done within a binary Crystal Report RPT format.  Recently at my work, due to a database upgrade resulting in a change in the underlying schema of the database that we report off of, I had to make changes to a myriad of reports. We have a table called DataPts (which is just that, a set of data points). Due to a format change in this table it was determined to change the name of the table to DataPtsEx (there was a good reason for this name). This is where the beauty of the RDL format comes into play.  All I had to do was to go into Microsoft Explorer and go to the top of the Reporting folder structure. Then I simply performed a search on all files that contain the text string "DataPts". Once I had the list I opened up each RDL and performed a Search and Replace on the string DataPts and changed it to DataPtsEx.  Since I use TextPad as my text editor of choice I could've easily created a Macro that would make this change as well.

This past week I made a concerted effort to utilize the flexibility of the RDL format by copying and pasting report parameters and datasets from one report to another by only using TextPad. If you have any experience with XML format, then identifying the various sections of the reports is very simple.  I am really starting to enjoy the ease of modifying a report simply using a text editor. One other thing that is really cool about modifying via a text editor is that if you also have Visual Studio open at the same time and you save the file in the text editor, it will prompt you to reload the file in Visual Studio. If you make a change in Visual Studio and you have a text editor open it will also tell you that the document has changed and will prompt you to save it. This occurs in TextPad but I have yet to test this in Notepad.

Next time I will delve into the various sections of an RDL file. If you have the chance, explore the RDL format in a text editor of your choice.  Start playing with copying various sections of the RDL file from one report to the other simply using a text editor like Notepad of TextPad. It will really open your eyes to a different wrinkle of report development. Until next time...

Ever since SQLServer Reporting Services (SSRS) burst onto the scene back in 2004 as an add-on to SQLServer 2000 (from Wikipedia), there has been an ongoing discussion comparing Crystal Reports to SSRS reports. The web-based reporting environment featuring Crystal Reports has now become part of the SAP BusinessObjects Business Intelligence Resource Center. The name of the Crystal Reports web-based solution has evolved in this sequence: Crystal Enterprise 9, Crystal Enterprise 10, Business Objects XI, Business Objects XI R2, and with the acquisition of Business Objects by SAP back in 2007, it is most recently included in the SAP product aforementioned. The evolution of the name from having 'Crystal' in the name vs 'Business Objects' was due to the acquisition of Crystal Decisions by Business Objects back in 2003.

Having developed Crystal Reports and administered the Crystal Enterprise and Business Objects Enterprise environments for the past ten years, I have focused on Reporting Services development for the past year. Using Visual Studio for my development platform to develop SSRS reports, there is a consistency here due to the fact that this is the exact same environment that I also perform Visual Basic.NET development.  Crystal Reports XI, which is what I utilize for my Crystal Report development, is just that, an application to develop reports.  A lot of companies either have already or are contemplating transitioning from Crystal Reports to SSRS reports.  My company currently utilizes both products for their reporting needs. Crystal Reports, in the web-based Business Objects XI R2 environment, are being used to deliver business-based reports to the internal ERP users while SQLServer Reporting Services reports are being used to deliver reports to our end customers.  The SSRS reports are being delivered either by way of subscriptions where the end customer receives emails with their reports either attached or embedded, or the end customer can view or execute their reports via a Sharepoint portal within a secure website.

 Performing a quick search on Google yields many different services available to convert Crystal Reports to Reporting Services reports.  It is my assertion that the best manner to perform this conversion is not through a service or a report generator but converting the reports by a human, preferably the developer who developed the Crystal Report.  Oftentimes this is not possible due to employees leaving companies for greener pastures but at the minimum if the conversion is done by a developer who knows both Crystal Reports and SSRS this is certainly preferable. In fact, if a developer is proficient with Crystal Reports, there is no better way to learn Reporting Services than to have to mimic the functionality of an existing Crystal Report in Reporting Services.

Developing Reporting Services reports every day for the past year, after having developed Crystal Reports for the previous ten, has certainly been a learning experience.  What I consider the most exciting aspect of SSRS is the RDL format. Since RDL is an XML-based format, which is familiar to most developers these days, the files can be opened with Notepad or any text editor! This is a huge advantage over the RPT format that Crystal Stores its report definitions in. If you try opening up a Crystal Report RPT file in Notepad you will see something like this:

If you open up an RDL file in a text editor you will see something like this:

The distinction here should not go unnoticed by developers. What this means is that you can easily peruse the file and go to any part of the report you want to change, make the change, and save the file.  So without having to be in a development environment you can change an RDL file which is certainly not the case with a Crystal Report.  Do not downplay this major difference between RDL and RPT!

Future posts will delve into the differences between Crystal Reports and SQLServer Reporting Services reports. With the evolving maturity of the Reporting Services product, any lack in functionality that there may have been between Crystal Reports and SSRS is diminishing.  Microsoft has done a good job of adding more functionality with each release, the latest being SSRS 2008.

In the meantime, I implore you to explore the exciting RDL report definition format.  It certainly changes the landscape when it comes to report development!