Once upon a time there were no reporting tools. Programmers would simply format a canvas, in your chosen programming language, and then dump that canvas to the printer. This approach was reviled by a lot of Computer Science types. You see, you embedded the very formatting of the report into the EXE file you distributed. This meant that lesser business experts could not modify a report. Only a programmer god could do something as elementary as changing to the numerical formating of currency values on a report. Every time such trivial changes were made, a new EXE would have to be compiled and distributed. Clipper programmers made out like Bandits.
Then there was Crystal Reports, and there was nothing else but Crystal Reports. Crystal provided us a with a relatively simple editor tool which resembled any other modestly powerful office application. You would point to a database, fetch sample results, arrange them on a canvas, and save out a report file. The *.rpt file defined what the report did, and what it looked like. You embedded the Crystal Browser inside your app, but the report defs were separate. They could be changed ad infinitum by any fool smart enough to use the editor. There were plenty of these guys. Now the reports could change, and the EXE would not have too.
There was a serious downside to all this. Crystal was not famous for durability, reliability, dependability, stability, and robustness. If you took a dependency on Crystal, you very well might be embedding a source of bugs in your app; bugs you could do absolutely nothing about.
If you were a PowerBuilder, Visual Basic or Delphi programmer, you had to rely on this crap. Various people attempted to build competitor products. I only saw one that worked... while externalizing the report editing function. Unfortunately, Crystal became the institutionalized standard. Microsoft and Borland both included Crystal inside their development tools. This was unfortunate. Microsoft and Crystal became business buddies. Crystal did everything Microsoft's way, until...
Then came .NET. Microsoft wanted to kill COM and ActiveX. Microsoft also wanted everything on the web. This horrified Crystal Decisions. You see, Crystal had built the entire plumbing of their system according to the COM architecture. It was all Visual C++ and Active Template Library. This stuff doesn't work well at all in a webserver context, and it doesn't play well with the CLR.
Basically, Crystal gave Microsoft the finger. They never changed their plumbing. Crystal is a COMmie technology to this very day. That is a very bad thing. The company was sold around to an assortment of different owners. There were several points in recent history where we openly questioned whether Crystal would survive. Unfortunately, nothing seems to be able to kill these bastards. This despite the fact that their product looks like shit on the web.
Finally, sometime around 2004, Microsoft introduced SQL Reporting Services. At first it was primitive, and I didn't like it much. It got better in a hurry. This system was built from the ground XML up to play beautifully on the web. The engine is written in fully managed .NET CLR objects all the way down to the core. It works great with .NET apps. The stability and reliability difference was like night and day.
Microsoft didn't do this on a whim. According to various accounts, they built their reporting tools reluctantly, under duress. They had to. Their partners at Crystal would not keep pace with the times. They would not introduce native .NET technology. They would not flush the COM. They would not fix their ugly web presentation. They would not get rid of the unsafe code running under the web server. They had to be replaced.
I stopped using Crystal altogether sometime early in 2005. I am very happy I did. There is nothing Crystal does that SQL Reports can't do better. SQL Reports can do anything better than Crystal.
Now, today, I am suffering this infamous tool yet again. We took delivery on an out-source tool that does not work. We terminated the firm's contract abnormally, without full-deliverables. This is because they could not deliver. They were a bunch of Java guys trying to write VB.NET. They did not do very well. The part that has to work is the IDLR reports. Forget what those are. The key point is that they are in Crystal, and they will not run. We are getting errors from within the bowels of the Crystal Engine. These are inner-inner-inner exceptions that are driving us crazy.
My mission is clear cut: Make it work. Don't replace these reports... yet. What fresh hell is this? Several attempts to upgrade these reports to the latest Crystal runtimes have failed. I'm digging deep now. This is dread man. This is truly dread-y man!
