Feed Icon  

Contact

  • Bryant Likes
  • Send mail to the author(s) E-mail
  • twitter
  • View Bryant Likes's profile on LinkedIn
  • del.icio.us
Get Microsoft Silverlight
by clicking "Install Microsoft Silverlight" you accept the
Silverlight license agreement

Hosting By

Hot Topics

Tags

Open Source Projects

Archives

Ads

Xml File with Report Data

Posted in Reporting Services at Friday, 02 April 2004 03:31 Pacific Standard Time

A while back Tom Rizzo posted some thing to try out in reporting services. I tried some of them out and asked a few questions. Tom responded in the comments section on my blog (which I think is pretty cool) with some answers. Specifically Tom answered my question about the usefullness of Reporting Services export to Xml feature:

A couple of good reasons to do it. Perhaps you want to control formatting of the report and use XSLT to transform it to HTML. Maybe you want to batch feed the report into another system that only supports XML. There are a bunch more.

In addition to Tom's suggestions, Rohan Cragg posts on how he has found this feature to be useful as well.

... If however they are willing to do this in two steps (ok, you'll need to give them a bit of training) they can export to XML, then import in to Excel 2003 and they can pick and choose the fields they want to display, and where, because Excel can work out the schema all by itself (well, sometimes!).

Ok, so as a Microsoft MVP for SQL Server Xml, I agree having data in Xml format is a good thing. I guess my problem is not with the function itself but how it is implemented. If you export a report to Xml using this feature you get some interesting Xml. If I have a basic report with a table in it, and that table's name is Main, when I export that report I get some Xml that looks like:

<Report ...><Main ...></Main></Report>

So I write some XSL to convert this to HTML as suggested and everything is good. Now let's say the developer decides to rename the table from Main to Table1 (or I just want to convert a different report). Now what does my Xml look like?

<Report ...><Table1 ...></Table1></Report>

How does my XSL run now? It probably doesn't run at all. I could probably create some XSL to could handle this by checking the elements location instead of its name, but what if the developer adds two tables to the report.

When I first saw this feature I was very excited because I thought I would be able to really extend the existing reports by creating XSL views of them. However, I quickly ran into problems since it meant I would have to really pay attention to how all the report developers named the objects in their reports. When you also factor in how everything is auto named based on field names, etc, you get some very messy Xml that isn't easy to write XSL against.

Now I'm not saying that the Reporting Services team did it all wrong and I'm sure they thought through this quite bit. However, it seems to me that it would make a lot more sense to have some kind of standard output format that conforms to a single schema rather than a separate schema for every report that is created. The report always maps to a Report element, so why doesn't a table always map to a Table element (with a name property)?

So that is why I didn't find this feature to be very useful. But, as always, I could be stuck inside the box of my own thinking and not seeing the bigger picture.

Comments are closed.