Your Crystal Reports Probably Suck

I know mine do. Since entering the grown-up job market in 2004, I've worked for three different companies, and I've been compelled to develop Crystal Reports for all three. In my current role, Crystal Reports development is a primary function for me. Why do my reports suck?

• I hate the designer. It's an absolute beast to work with. It's reminiscent of old-school code-behind techniques in WinForms apps (wait, you don't still use code-behind, do you?). Sizing and placement of elements is temperamental at best, but it's usually just sadistic. For example, add a simple element and note its height and width. Then re-size it to whatever, then try to go back to the original sizes without explicitly entering the values. Good luck.
• I've recently noticed that right-aligned string values and numeric values don't exactly line up; they're maybe off half a pixel or something. Why?
• For some strange reason, when printing to PDF, Crystal Reports shrink the font sizes by 5%, completely screwing up any effect you were trying to achieve. Supposedly, this is due to fear of cut-off text, but that's my job as a developer to test, and our testers to test, not for Crystal Reports to force upon me. There isn't even an option to disable this without resorting to the registry hack described in the link. Of course, that hack only works if CR2008 is installed on that particular machine; if you actually utilize a report server that does not have CR2008 installed, to the best of my knowledge, you're out of luck.
• This all makes me not really care so much. I see the reports I have to develop as punishments chores, and when I'm done, I get to do cool stuff again. Net effect: I generally put them off until I absolutely can't any longer, and then I simply rush through them.

On the rare occasions I've worked with Crystal Reports without blinding, white-hot rage, I've applied my Lazy Pragmatic Programmer principles and come up with some tips to help me at least inch away from the ledge:

• Source control all of your reports. Every single one of them. Odds are, if you're developing Crystal Reports, it's in conjunction with software development, so include them in actual projects. You will screw up one of your reports eventually. If you don't have a legitimate source control system, yell at someone at least try to get by with keeping production versions in different folders than ones in development, and archive reports by version.
• Use formulas everywhere. Trust me on this one. In all of my reports, there is not one instance (I hope) of using an actual database field in the report itself, groupings, record/group selection, formatting, etc. I have tons of formulas, and most of them are simply an interface to a database field. I once had to convert a stack of reports from using an actual database connection to reading from an XML file, and those reports all used regular database fields in the reports. So, I had to go through the pain of removing all elements from the report, re-adding new ones, then screwing around with the size and position for each one until it was right. Due to the weird size/position issue mentioned above, that was impossible without getting a screenshot of each individual element's size and position, pasting that to MS Paint, removing the element, adding the new element, then manually setting the size and position based on my screenshot. That sucked. A lot. I learned right then that, if all of these database field elements had been formulas, I could simply update the formulas and not worry in the least about adjusting the sizes and positions.
• Use a report template. In most use cases, you will have more than one report that's meant to be included in an overall report package, variations on reports, or other situations where a consistent layout is key. The easiest possible way to do this is have a base report that you use to create all new reports. This will let you keep things like header/footer sizes, page number positioning and other layout issues consistent without having to really worry about it. I haven't done this part fully, but I also would recommend including every possible formula you could want in that base report; that way, they're all there when you need them, and you can remove the unused formulas and database tables from the new report to save on overhead. This way, you really only have to worry about the data you're going to show and how you're going to present it, and you can forget about all that very tedious plumbing.
• Don't connect directly to a database. If you can't control this one, buy gifts/beer for the people that can. In our main line-of-business app, our reports used to use standard database connections. However, we moved to an ASP model where all of our clients are actually hosted on one database. From the app, it's relatively trivial to ensure that clients don't see other clients' data. However, if a client wanted to create his/her own custom report, he/she would have the keys to the kingdom (db connection credentials, access to all data, etc.). So, we had two choices to make:
  1. Don't allow clients to create custom reports (meaning I'd have to do it...), or
  2. Utilize a report server that creates an XML file with the data needed for that particular report.

  Going with option 2 has been an absolute life-saver. Basically, when a client requests a report, the request is offloaded to a report server which populates the XML data, then that DataSet is used for the reports source, and we're off and running. I don't have any real metrics to back this, but it also seems that these reports ran much faster as opposed to their database-tied cousins.

• Don't program in reports. Crystal Reports has all kinds of programming functionality in it, and I've had to use it quite a bit. However, if you can utilize the report server/XML DataSet framework, your report server developer (ideally you) can write whatever functions needed in the report for complex calculations. Not only does this allow much faster report development, but if for some reason you're not utilizing the base report tip above, you won't have to reinvent the wheel for all of those complex functions.

Granted, most of these tips are really workarounds for my hatred of Crystal Reports; I'd rather spend 2 hours in Visual Studio than 2 minutes in Crystal Reports. However, these tips also follow the DRY principle, so hopefully you can use these to help save yourself some broken stuff time. Please feel free to share any other tips in the comments.