4130 Google hits agree "crystal reports sucks"; is this a legacy code auto-conversion opportunity?

reputedly Crystal Reports is hard and inconvenient to use (not sure, I myself am happy camper with XtraReports, but Google test gets lots of indignant hits) plus presumably not every company with legacy code in Crystal Reports can locate a competent developer for it at any given time.

Could this be a market opportunity for a software tool or a software tool assisted outsourced service that would convert legacy Crystal Reports apps into apps for another reports environment, whichever is most convenient and popular with programmers?

If you happen to be familiar with both Crystal and another reporting system, what is your take on the inherent structural similarity or lack thereof of the resulting apps? Do you think you could teach a hypothetical super-intelligent reports converting e-monkey ™ to do this sort of conversion by means of copy paste (the term used loosely; in practice probably more like automated source code parsing/rewriting) and simple heuristics?

I’m not sure what you mean, but I used Crystal all the time form '99 to '03. I didn’t like it as much as Access, but what I would do is this:

Design Crystal Report
Run it
Export it to CSV
Import to Excel

Distribute on Excel to everyone, cause everyone understands Excel

The only problem I had with Crystal was poorly made databases. If you have people dumping junk into your database, Crystal can’t pull it out.


1) It's easy to get everybody to agree "XYZ sucks". But it's much much harder to get them to agree what should be used instead. Everybody prefers a different alternative. 
2) Most of the people who think Crystal sucks aren't looking to use a different package, they're looking to write their own package. IE, "All I want is to select * from a table and dump it into a HTML file -- why do I have to spend hours learning their weird API? Why can't I just write my own custom python script in 15 minutes?" These people would feel the same way about your package.
3) Your package is brand new. Your first 2 or 3 versions will inevitably be missing some feature I'll probably need. But Crystal, for all its faults, is very mature and has every feature anybody could ever need. Why should I take a risk on using your package in my application?
 4) Crystal has a namebrand, an active user forum, books written about it, my coworkers have used it before and know how to workaround its limitations. Yeah it sucks, but at least we know how to use it. What happens when I can't figure out how to do something on your package? Where will I go for help then?
 5) Why should I believe you're app will be any better? Crystal sucks, MS Access sucks, DevExpress reports sucks. The nature of the game is you either make things simple-and-easy-to-use (but not much flexibility) or you make them very flexible (but then there's a tremendous amount of complexity and it's hard to use). Very very hard to strike the right balance with a reporting package, and there's no reason for me to spend the time testing your project without a good reason to believe it's better.
6) For your converted program to work, it would have to be 100% compatible (including bug-compatible) with what I have now. There's thousands of rarely used features in Crystal -- can you guarantee to automatically convert every one of them perfectly? If your conversion makes my report look differently, even by just a couple pixels being shifted to the left or using a different font or something, then that could potentially break my report. 
7) Even if your package really is better, I still have code using Crystal that works now. You may have a new API that's better, but I still have to invest time learning it. I don't have time to rewrite my code, or to look over it after your conversion to make sure you didn't break anything. I've already paid the sunk cost of learning Crystal, and it is now a defacto semi-standard. Your tool can't justify the switchover cost by being slightly better. You'll have to be A LOT better to justify the switchover cost. Can you guarantee that?

In all honesty, I’ve used Crystal reports to create custom reports for end users of a software product I worked for. It was version 8I believe, as it’s been a few years since then.
I’m not the sharpest tool in the shed by far yet I learned to use it with very few issues other than an occasional file recognition problem.
I’d would say if far from sucks, however, I’ve heard that the later versions are more temperamental than the one I used. Just my opinion.

What I used to see was that a good portion of the Crystal Reports sucks is actually misplaced - the database that they’re trying to use Crystal Reports on was often the real issue. They saw the difficulty as being CR because that’s the tool that they interfaced with, but even using a plain SQL query tool would have given them just as big headaches. Their database was just poorly designed.

If that’s the case, your auto-convert tool would change nothing, unfortunately.