First off. Someone get me the head of the guy who came up with this Crystal Reports crap.
I spent the better part of 2 days trying to get this garbage to work. I haven't seen such a travesty of engineering since SMS (2.0 or 2003, it doesn't matter). The following is a detailed list of the painful issues that I was forced to endure simply because of the poor documentation and hideous design of Crystal Reports.NET.
- CrystalReports.Engine.ReportClass, no overload for a method: Despite the ReportClass's signature, when creating a new object you can not pass in any arguments (such as the rpt file class). Try it, I dare you. Ignore VS's helpful popup stating that you can... I promise you. You can't.
- Access to report file denied: Crystal Reports says that it is unable to write the file to the destination. Specifically the magical temp directory that CR picks automatically based on the the user running the report. This error is a bold faced lie. It turns out that the error has more to do with the output directory than the TEMP directory for which CR gives you the error on.
Fix: Apparently READONLY was set on the output directory... but unsetting the bit did not work even with local admin. So, I deleted and recreated the temp directory, turned off inheritance, added ASPNET to the output directory's ACL, and attempted to unset the READONLY attribute (that had somehow reset itself). Still didn't work, but the report file ran magically after this process. I have no idea why.
- File does not begin with '%PDF-': As usual this error tells you nothing. However, it crops up if you attempt to read the filetype you Export()'ed with CR before it finishes. Apparently CR does not stop execution while writing... it simply spins off a thread to accomplish the export.
Fix: Do not attempt to do a Response.Flush, Response.Load, etc. Just do a Response.Redirect() to the PDF. Ignore the posts you find via Google Groups, nothing else works.
- Login failed: This problem is another stellar CR error. Near as I can tell, credentials to the SQL Server are trapped in the RPT files binary format and are not exposed via the UI AT ALL. Most likely you are seeing this error because you are trying to run a report (RPT) created by someone else using their credentials... and since you have a different user/password - it fails during pass through authentication. Fix: Delete the file and start over.
- DataSourceException, Query Engine Failed: My guess is that this is due to the way in which I get the CR report to "understand" the data I send to it.
Fix: Unknown. Still broke for me.
While working with this crummy product, I began to codify a process. One that would be repeatable, providing consistent, reliable results. LOL - at least one can hope. As a part of my process, I write an XML file from the resultant dataset (which I build using various stored procedures in SQL Server 2000; each procedure outputs a variable number/type of fields depending on the input parameters). The XML file is then added as a new ADO.NET datasource by using CR's Report Expert (which can only be started when creating a new report, not when modifying an existing one; the dialogs are completely different when editing the datasource later - ie. different tabs, and are not easily found, ie. right click the rpt design surface). If you don't fix the XML file you end up with datasource names like dataset and table names like table. Once you have successfully added the datasource, you can drop select the fields that it exposes. The wizard then walks you through configuring the report... and dumps you back out to the CR Designer interface. This interface is remeniscent of Access (pathetic at best).
NOTE: The CR ADO.NET data provider is so lame... that you can NOT delete ANY previous datasources. So if you made a change to the XML file and try to reload it - sucks to be you, because CR won't allow you to re-add a datasource with the same name. It also ignores any changes to the file.
Workaround: Rename the file before you import it again; however this time remember to change the XML file root nodes to reflect the name of the dataset, and the name of the table.
My guess if anything went wrong with the way the data is consumed at run time, CR throws the DataSourceException. But at this point, I have no way of knowing what went wrong... and thus no way of fixing it. I'm glad that Microsoft has recognized how bad this product truly is... by creating SQL Reporting Services. Excuse me while I go try that one instead.
!@(*#%)+*^#%!
posted @ Wednesday, December 22, 2004 6:09 PM