Fog Creek Software
Discussion Board

SQL Server Reporting Services Output

According to this article, the service supports the following output formats:

"The tool can create reports in XML and generate XML schema descriptions (XSD) as well. Reporting Services also supports HTML 4, TIFF, PDF and Office Web components (OWC) output format."

What about viewing reports in fat client applications? Personally, I don't want to use HTML, PDF, or OWC for these reasons: HTML doesn't always print right, PDF is slow and the files can be huge, and OWC requires Office. So, I'm left with TIFF?

Also, is XML/HTML my only option for distributing the report and the actual data separately?

Is there a viewer component besides the web-browser control that has a nice interface for accessing the groups and showing/hiding sub-reports?

The reason I ask is that there are some people (ahem - Philo) who recommend SQL Reporting Services for just about every situation, and with those limited output options I just don't see it as the answer to every situation.

Personally, I like the control that you get with the Crystal Reports model.

Tuesday, August 3, 2004

Visual Studio 2005 has a Reporting Services control that you can embed in a winform.

"The reason I ask is that there are some people (ahem - Philo) who recommend SQL Reporting Services for just about every situation"

I recommend Reporting Services when it seems appropriate for the solution and the platform. I apologize if that happens to be "often" ;-)

I've deployed production applications with Crystal, ActiveReports, and I've worked with SQL Reporting Services. I have to say that I prefer Reporting Services. May I humbly recommend you try out each before claiming one to be the only viable solution?


Tuesday, August 3, 2004

By the way, Crystal uses a proprietary format for its reports. Reporting Services uses RDL - a documented, open XML-based standard.

Just wanted to let you know.


Tuesday, August 3, 2004

So if you don't think there's only one viable solution, when would you *not* recommend SQL Server Reporting Services?

Also, why wouldn't there be only one viable solution? Reporting is pretty straight forward, so it comes down to quality of output and flexibility. (BTW, I've tried ActiveReports and taken a cursory look at output generated by SQL Server Reporting Services and I wasn't really impressed with either, but hey that's me.)

"Visual Studio 2005 has a Reporting Services control that you can embed in a winform. "

Hmm, well this is another reason why I asked. What about VB6 or other COM based environments? Is it just a wrapper for the HTML output? Also, does it provide programmatic access to the underlying report model? What about drill-down and sub-reports?

"By the way, Crystal uses a proprietary format for its reports."

The only way that I can see that being an issue is if the vendor goes out of business AND the code components needed to create/view reports was not royalty free.

I wonder if Microsoft will patent their XML format like they did with some of the Office document formats? (I don't think this really matters any more than if it were proprietary, this is more of a rhetorical question).

Anyway, I might recommend SQL Server for web-based reports since it can output nice HTML reports (better than Crystal's HTML export from the output that I've seen). But then I tend to stay away from completely web based applications for too many reasons to list.

Tuesday, August 3, 2004

I can't resist picking Philo's brain here.  Any idea when we'll see the VS 2005 control you were talking about?  Beta 2?  When might that be?

As someone who has toiled for 5 years with many aspects of the Crystal Reports API and dealt with the various incarnations of Crystal, Inc., I look to this component as a POW looks to escape.

Yes, Crystal is _THAT_ bad...

Bill Carlson
Tuesday, August 3, 2004

I concur.  Crystal is freaking horrible.

Tuesday, August 3, 2004

I understand that I am in the shrinking minority here, but I am honestly struggling to figure out why. Maybe I am ignorant of some aspect of the Crystal API (you mean CRAXDRT right?).

What is so horrible about Crystal? The last time I asked this, the response that I got was about how bad the actual report designer which I know has a few minor bugs (like field-layout getting messed up when moving them sometimes, etc.), but nothing about the 'API'.

The really confused because I basically have one function that I use to view a report after it's data has been retrieved. It hands a Recordset or two to the report and then hands the report to the viewer and it's done.

If I don't want to hand it to a viewer and I want to save it to disk or export to be distributed, that's another function.

Someone please tell me, why does the API suck??

Tuesday, August 3, 2004

correction: how bad the actual report designer IS,

Tuesday, August 3, 2004

Also, I've only been using Crystal since version 6, if you're talking about historical problems, I don't think that it applies.

I will tell you that I had a hell of a time trying to figure out the dll dependancies the first time, but that's probably the worst problem I've had.

Tuesday, August 3, 2004

Here it is:

Seek the reply by Justin about the 'convoluted API' (with no examples).

By the way, you'll notice that I did not recommend Crystal for this Java application as I know nothing about Java. I just wonder why people seem to detest Crystal in general.

Tuesday, August 3, 2004

Fair questions, Wayne.  A couple things:

* Difficult to deploy DLLs correctly.  Different dependencies with 98, 2000, etc.

* DLLs don't follow normal loading conventions.  Crystal looks for DLLs in places it shouldn't.

* Each of the export DLLs has it's own set of problems.  Rows being dropped, bizarre formatting, etc.  Most export formats are basically useless.

* Unable to redirect database when running off SQL Server.  Have to use strange workaround.

* Often the viewer will misplace text, showing it on top of other text - while the report prints fine.

* In 9.0+, the report insists on verifying the data source when the report is loaded.  If you're remapping, this can take 30 seconds for the verification to fail and the report to allow you to remap it.

* The windows forms viewer does not propogate DB authentication information.  Their response: "Yes, it's a serious bug.  No, we have no plans to fix it."

* The merge modules are fat and add thousands of registry entries.

* Products using Crystal can break other products which use a different version.

* Their .NET solution is a .NET Viewer wrapping a hidden .NET doc model wrapping a COM DLL, wrapping a Win32 DLL.

* We've spent much time finding specific DLLs version which work together.  Taking a snapshot of a monthly hot fix often isn't enough.  You have to mix them.

* They've been bastards about their certification program.

* They have nice support people, but rarely can they solve a problem.

I could literally go on for hours, but this does make me feel a _little_ better!

Bill Carlson
Tuesday, August 3, 2004

Wow Bill! That's a big list. I have to agree with you about the useless support, unorganized patches, terrible backwards compatibility and shoddy DLL organization.

I am lucky to never have had anything on your list be an issue for me since I have stuck to a very simple method of developing reports since version 8 and that is to use the ADO driver.

Using the ADO driver, CRAXDRT doesn't have to connect to the Database file/server, which minimizes a lot of those annoying database connectivity problems (like authentication errors) and having to distribute a bunch of DLLs.

Before version 8 I do remember having a few of those types of problems.

I guess the other reason that I haven't seen a lot of those problems is because I have always worked for small companies or as a consultant, where the runtime environment is under tighter control.

Regarding SQL Server Reporting, I think that in a controlled environment (like the enterprise) once you have worked out any issues like DLL dependancies and such, Crystal is still better. Then again, I think that Fat/Hybrid clients is the way to go as well. If web stuff in general were more robust, SQL Server might have the edge.

For a shrink-wrap/shareware app I might use ActiveReports if there's a need for reporting because then those DLL and support issues become a bigger liability.

Tuesday, August 3, 2004

"I think that in a controlled environment (like the enterprise) once you have worked out any issues like DLL dependancies and such, Crystal is still better"


Philo [Microsoft]

Tuesday, August 3, 2004

Because it's got the best designer out of all of them, it's not a .Net only, it doesn't require a server install, and it has a viewer that has comparitively better client sided capabilities than what I've seen from the other two (like on-demand sub-reports, live formula updates, charting, etc..).

Hey, you're asking questions out of order Philo! :)

You didn't even answer one of my questions :(

Wednesday, August 4, 2004

OK, the other two might have charting but do the charts have good design time support?

Wednesday, August 4, 2004

Philo, I also want to let you know that I'm not trying to attack you here.

I just feel that the SQL Server Reporting Services is pretty bare-bones in comparison to what you can do with Crystal.

This is probably driven by my enjoyment of delivering slick client-side features like being able to export something as a PDF or RTF file without having to go to the server, or having a drill-down menu.

Wednesday, August 4, 2004

Anyone battling with Crystal owes it to themselves to investigate Infomaker...

Wednesday, August 4, 2004

Crystal is considered bad, or hard, or difficult because of its history. 

I haven't used it for a very, very long time and the experience wasn't one that encourages me to get into finding out whether its improved or not.  The above list suggests not.

Brands are important, but if a brand gets a bad name then sometimes the best thing to do is to ditch it.  Business Objects might well have bitten the bullet and rebranded at the time of acquisition.

Incidentally, when the acquisition was announced MS made reassuring sounds about continuing to provide Crystal in Visual Studio.  Now I know Reporting Services is a server application and you currently need a full version of SQL Server but I wouldn't put it beyond the realms of possibility that Reporting Services suddenly popped up in the Express product family.

Simon Lucy
Wednesday, August 4, 2004

I stumbled onto this thread and had to stop and add my t bytes worth...


There! I said it! I feel better now.

If you have ever tried to debug someone else's report (or even your own for that matter), which has any amount of embedded code, you will say the same thing.

With Crystal you can embed whole subroutines behind a single field on a sub-report, and the only way you know that code is there is to drill into the report designer and search for it field by field. Now try debugging a report with dozens or even hundreds of such fields!

Unless CR has gotten a lot better about telling you what code is embedded in a report, field by field, then I say stay away from it. It is fine for producing simple reports, but as soon as you start introducing complexity and custom coding, look out.

Wednesday, September 1, 2004

*  Recent Topics

*  Fog Creek Home