SelecTViews
With Stephen Wynkoop
Check Out SelecTViews to hear about a new Heavy Lifting Database Engine called UnQL from CouchBase.
Backwards Compatible Reports for SSRS
Yesterday I introduced an issue one of our reader faces by having to support older versions of SQL Server Reporting Services, while taking advantages of the new features of the current release. I didn’t receive any input from our readers today, so I thought I would examine a few options I might consider.
- Create all Reports in SSRS 2005, lowest common denominator
- Write a utility to convert Version 2008 reports backward to 2005 specification
- Cut off backwards support for newly developed reports. Any customer wishing reports that aren’t compatible with both versions would either have to upgrade, or pay for custom coding
- Don’t Use Reporting Services; Use Embedded SSRS report control instead
- Don’t use Reporting Services at all
- Maintain two different code branches
Clearly a developer won’t have the luxury of making many of these kinds of decisions. But here is an overview about how each of these might work.
Create All Reports in SSRS 2005
SSRS 2008 supports the definitions of previous versions. You could simply take the approach of using only those features in SSRS 2005. Then everything you define will work in both worlds.
Write Conversion Utility
Reporting Services uses an XML specification to define report layout, data sources, and data binding called an RDL. This RDL is pretty easy to understand. It is possible to write a utility to translate the RDL into a form compatible with its ancestor. This may not be that easy since SSRS 2008 has many different new capabilities that may not translate well to
SSRS 2005.Cut Off Backwards Support
This is a common approach for most companies writing software. There comes a time when it costs too much to maintain older versions of your code. Your customer’s budget is driving your technology.
Don’t Use Reporting Services
This approach still uses the same RDL files you define in Visual Studio. The difference is how the final presentation is created. In this case, your application is doing the data gathering, binding, and presentation. You do not have a centralized service handling this work.
If you use this approach, then you are not constrained to the budget of your customer, nor do your customers have to purchase an expensive infrastructure to host your reports.
The downside is you no longer have the additional features of reporting services. You will either have to do without, or build your own support infrastructure for scheduling, distribution, subscription, sharing, etc. already found in Reporting Services.
Don’t use MS Reporting Tools At All
This option is much like the previous. The difference is that you are going to use another third party reporting tool such as Active Reports, or an open systems tool. I read a few years back about the designer of the Power Builder Data Window creating a reporting engine based on the RDL schema capable of producing reports.
Maintain Two Different Code Branches
This option is the least attractive because it requires twice the work. Basically I would use a baseline of reports that already exist in a common branch in version control. Any new reports that vary would be maintained in a separate branch for 2005 and 2008 versions. You could easily give them the same name as well.
Packaging becomes the key capability at this point. You would probably want to have a more intelligent install program choosing from the appropriate repository based on the version of SSRS where the reports are being deployed.
Do you have any options you would add? I’m sure there are other options; probably some better options. Send your thoughts to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using SQL Server 2008 Integration Services (Part 2)
In this article, you can find some helpful tips to performance tune and optimize SQL Server 2008 Integration Services.