Lets face it, the longer I work as a developer, the more opportunities I get to work with crappy software tools. Crystal Reports is beginning to look like a perfect fit in that category.
I realize that I am weighing in on something that (from my forays into forum posts) is pretty much a religious war. Evidently there are those that love Crystal Reports, use it daily, and consider it invaluable. There are also those, like myself, that loath it.
I have read many arguments. Both sides claim that the others viewpoint comes from one of either stupidity, inexperience, or both. I have seen claims such as:
"I use Crystal Reports every day, and in thousands of reports, and its perfect. Once you have mastered it, its great."
I have also seen something like this:
"I was forced to use Crystal Reports every day, in thousands of reports. I was able to achieve some success (albeit painful), but I hated every minute."
I am definitely more towards the second. Although I have not necessarily used it to the extent that some persons undoubtedly have, I have definitely formed an opinion:
The IDEA of CR is excellent. Data is crucial to most applications, and visualization of that data is valuable to customers. Customers like to tweak, so why not have "expert tools" for the creation and modification of data reports! Brilliant! Bravo!
The implementation of CR that I am forced to work with (8.5) is shaky at best. I do put the following caveats on my opinions:
- I am stuck with XML documents as my data sources
- I am also stuck with a lame ODBC driver to access the XML, and it has its own host of limitations and issues. (Only INNER JOIN is supported, for example)
These are not necessarily the fault of CR. They do, however, compound the frustration.
I think that the standard approach of CR to reporting is decent. The concepts of reports and sub-reports, grouping, sums, macros, etc. are reasonable. For most every case there is a "tool" that will allow you to get your job done. However, each "tool" is essentially coated in shop metal shavings and fiberglass.
That is, once you understand each tool, you then have to (painfully) figure out the limitations of the tool. This is a process of trial and error, and the limitations of each tool are often surprising and certainly not intuitively "knowable" [for me at least]. I often found myself thinking: "Why is that how this works?" or "Why is it that this does NOT work?"
The people most likely to appreciate CR seem to be those that started with it. Its like a programmers first language; it holds a special place in their heart and you never see the faults of a well-loved friend. For me, CR was like picking up a hammer to hit in a nail only to find that the hammer's head was made of nitroglycerine and the handle had it in for my shins. As a developer, I know what problem I am trying to solve. I also, intuitively, know the standard approaches to the solution. CR just comes across as 180 degrees different from what I would consider to be the "standard approaches".
Every single "tool" in CR has its sharp edges and its quirks. Sure, I can learn to avoid the edges and get stuff done eventually, but why are these problems still there in an 8.5 release?
Here are some more concrete examples:
- Moving and resizing elements with the mouse is VERY imprecise. Even with grid and snaps turned on, three element "moves" to the same grid location will yield three different actual X,Y positions. The only way to consistently place items is to use the arrow keys. That is, you move the element to either the top or left of the active cell, and then back to where you want it, counting the number of key presses. This is the only way I have found that allows you to position two or more elements aligned on the X or Y axis.
- Table support is non-existent. I was surprised to find that the existing report I was asked to update emulated tables through the use of horizontal and vertical lines that happened to display such that a (slightly off-kilter) table emerged. I immediate tried everything I could find to try and avoid this painstaking approach, but was thwarted at every turn. In the end, I had to follow suit, to the extreme of moving every single element in order to insert a new "column". Has no one ever asked for a line-ruled table report before? My client's client did, and thus this ugly reporting "hack".
- XML data is inherently hierarchical. The report requirements essentially required that I flatten the hierarchical data into table "rows". The problem is that the two methods of flattening (or sub-querying if you want to call it that) are both crippled. Sub-reports are great! They fit the bill perfectly, or at least seemed to until I ran into the brick wall. You cannot nest sub reports! I'm sure that this was done to protect users from themselves and ensure some level of performance. Effectively for me, however, this meant only a single sub-query level. Yes you can have many sub-reports on a report, but you cannot have a sub-report inside a sub-report.
- Grouping suffers from different limitations, but with similar results. Grouping allows for functionality similar to the GROUP BY clause of SQL. However, grouping soon self-destructs as soon as you realize that you will need many nested groups to account for the levels, and that this is just not compatible with the single row you are supposed to generate.
I understand that, in some ways, my requirements are a function of my data. I know that I can use XML tools like XSLT and do all manner of flattening and grouping so that CR can display the data. However, that means that instead of using CR to account for customer specific report requirements (one of the primary reasons for using it), I am now using another customer specific layer because CR cannot handle the native data output of the application, and all the client is wanting is a "simple report" (from their perspective).
I am beginning to see, upon better acquaintance, just what a practiced CR designer can do comfortably. With practice, you CAN play Jenga with your feet. Just don't try to do anything "fancy".
To you CR veterans:
Does CR get better in later releases? Are there any good alternatives in this space?