bitching about reports v2.0 - how about a restricted but nicer clone of Crystal Reports?

this thread is inspired by this article from which I shall quote a large segment that is of particular interest to me in the framework of this discussion. The quote reflects the opinion of the author (so if you think he is full of it, don’t be shy to fight my ignorance of that) whereas I personally am not sufficiently familiar with CR to argue one way or the other.

The main question that I want to discuss here is as follows. This guy is claiming that Crystal Reports is an environment in which the nonessential complexity of working with the interface is way too much, above and beyond the “natural” essential complexity of making the report (well, that’s not his precise words, but I think a fair summary in light of No Silver Bullet thesis). The biggest issue he names is poor reporting of errors (which I quote), but there are a few others (see the article for details). Based on this, I want to ask - if Crystal Reports is an inevitable fact of life (for legacy reasons) and if it is so darn hard to work with (because da man done said so), why doesn’t somebody make a “Crystal Reports Lite, Restricted” environment that would have the following characteristics:

  1. its underlying model would be the same as Crystal Reports, and so porting an application from CRLR to Crystal Reports would be a purely manual process

  2. its expressive power/functionality would be a “sufficient” subset of CR. Well, lacking the CR internal documentation, probably nobody can even spec out a full clone. But a highly restricted imitation, “just what we normal users need” IMHO should not be impossible. To be clear, I do realize that what I am talking about here is a clone of the feature, not of the implementation details; so if CR has weird implementation quirks in some features that nobody really knows systematically, it will likely not be reproduced. Then again, the simpler and smaller the subset of features gets implemented, the less likelihood of having problems with that.

  3. it would have good error reporting, good user interface and generally be full of light and goodness

Why would we want to create such a hypothetical tool? Well, if making the report in CR from the start is so darn painful, why not make it in this CRLR, debug it until it works, and then dumbly/mechanically type it into CR (or hire an minimum wage intern to do it for you)? That way the report is created in the environment optimal for creating reports (i.e. CRLR) and it is deployed in the environment we are forced to deploy it to (CR).

So, if you happen to be a CR expert, what’s your take on this? Are the claims of the guy in the article total BS? Is what I am proposing a great idea? Are the claims of the guy truth and nothing but the truth but what I am proposing will not fly for a bunch of reasons that you will share in this thread?

And now for the long awaited quote:

As already noted, he also bitches about some other issues, of which I particularly noticed the weird need to change every property of every item using a dialog rather than using generic styling or xml editing. But I just don’t want to clutter up the thread and also consider the complexity of debugging to be by far the greatest reason to bitch about and/or desire to replace a software framework. Bad GUI wastes hours but ineffective troubleshooting and debugging wastes days or even weeks.

Instead of re-inventing - If you don’t like Crystal Reports, why not just use a different product?

I don’t see this as a General Question with a nice factual answer so I"m moving it to IMHO.

samclem Moderator

why didn’t the guy that I quoted use a “different product” instead of CR? Do you, RaftPeople, suspect him of being an idiot, or are you willing to grant that sometimes people just have no choice as to which framework to use, even if what they end up with really, really sucks?

No, I don’t suspect him of being an idiot.

You can do anything you want with computers, so the answer is always from the perspective of economic efficiency. So, buy a better product and maybe spend some money on writing a conversion for existing CR into the new product.

Other than that, not sure what you are looking for as an answer - developing a clone of CR will certainly cost more than purchasing a competing product.

RaftPeople, why not cut down on glittering generalities (of which I am probably aware, being a professional in the field) and focus on the OP? If lots of people have to use CR and have no choice whatsoever about switching to another product, and if (as this guy claims) they are less productive than they could be because of CR problems, there may be a need (a market) for the hypothetical product that I have described in the OP. So this thread IMHO should focus on issues such as:

  • is CR really so sucky that people would be a lot more productive if the issues the guy described are solved
  • is there any reason to believe that the sort of limited cloning of CR, such that mindless transfer of a document from CRLR to CR were feasible with very infrequent incompatibility glitches, that I have described is not a feasible project
  • are there other factors that may prevent the proposed approach to speeding up CR development from working well?

Whereas what it should not focus on is argument by mockery and dismissal out of hand.

I thought you were talking about doing this for internal use, if you were thinking of making a product and selling it, then there may be a market for it, although you may run into IP issue with SAP regarding the formatting of the report definition.

not sure what you mean by “report definition”. The OP does not propose to reverse engineer the CR file format (that would be great, obviously, but notice that I explicitly specified manual translation from one format to the other). Or do you mean that the sheer visual similarity of the two designers as well as of the behavior of the resulting app to CR (one, after all, is supposed to be an imperfect clone of the other) would constitute IP infringement?

“report definition” is all the “stuff” CR stores when you define a report. It’s the layout, the field attributes, everything. It’s what tells CR what the report looks like and what it’s going to do.

Yes I was talking about file format.

When you say manually translate, do you mean using the CR report designer (whatever it’s called) to then manually define a report that matches the one you did in the clone?

If so, what have you gained by doing this?

:slight_smile: I agree that the OP is a bit long. But you should still read it carefully :slight_smile:

What’s faster - to develop a program from scratch in an environment that sucks or else to type an existing, working program into that environment? If fairy godmother gives you a working 10K lines of code in Brainfuck, would it be easier for you to just type them in or to develop them from scratch in the (hypothetical) Brainfuck IDE?

Whether that is a fair analogy to what is happening with CR development or not, well, that’s just one of the issues that I am proposing to discuss in this thread.

Crystal Reports isn’t an IDE, I don’t know where you could type “code” in.

A lot of options in CR are accomplished by say, using the user interface to create a sub report, setting up properties of the sub report etc.

You could use a light weight third party program to say, generate the SQL statements you might need to type into CR. However, those are typically not what’s hard about getting a report to come out right. It’s rather navigating through a huge GUI with lots of vaguely named options, contextual menus and et cetera. Compounded by the fact that I think a lot of people who use CR don’t use it every day but more like every month or so, so they often forget things.

I’ve seen CR used a lot where someone will create a few reports, set them up to run automatically and then they won’t mess with it again for a long time. So in the interim they sort of forget all the weird menu items, the contextual menus in sub reports and et cetera.

If there was just some sort of place where you could type in the report definition as XML and do everything in text, your idea might work. To my knowledge that isn’t how it is done. You’d have to perhaps manually edit the .rpt file or whatever it is CR outputs these days, and if I had to guess those files probably aren’t easily edited in a standard text editor.

I also question the premise of some “business need” for Crystal Reports. Business end users don’t need Crystal Reports, they need reports. If the technical staff want to use Telerik Reports (I recommend) or another Reporting tool the business end users won’t care too much. Especially since the license cost for many of these products just isn’t that expensive on a per user basis (in fact CR is the most expensive so going to another option may be attractive to business end users.)

The only time I can imagine someone would be required is if a member of the technical staff is told by their boss to use CR because the boss has made the decision that their organization will use CR as the reporting tool. In that scenario I think most bosses, and I know this is how I would feel if I was a manager of data analysts and etc (I’m not) is that I’d want my employee to learn to use the tool that is part of the responsibilities of the job, not some weird tool that pseudo-completes the process for him. Learn those intricacies and make it work, CR obviously isn’t unusable crap or it wouldn’t have such a large user base. If we needed a tool like you’re proposing my solution would be to find a new reporting tool, not to buy an intermediary tool.

Martin Hyde, thanks for joining the thread. I was concerned that I wouldn’t get much response once this got removed from GQ, and to some extent that proved correct :frowning:

Though not a CR expert, I am aware about how it works. Please don’t nitpick on word “type” (or any other word) in my hypothetical analogies. If a report has to be copied from fairy godmother / CRLR / any other source to CR, it is implied that it will be entered using the existing interface.

If you carefully read the OP and my subsequent responses to RaftPeople you will see my argument for “why should we first develop in CRLR and then copy to CR”. This argument has certain premises that may be false (and then you should call them out as such), but you should start from understanding it fully rather than making me restate it for you (or, for that matter, for every new commenter in this thread).

I don’t disagree with your second post about using other reporting solutions. And yet, I notice that plenty of people still use CR. So perhaps among the set of those who use CR there is a subset of tasks for which my proposal would be a big benefit. Or perhaps not because it does not work, violates 2nd law of thermo or else is inherently incompatible with realities of legacy support. One way or the other, discussion should concentrate on that and not on “let’s just use another tool and stop discussing CR” line of thought.

While what you say about possible reactions of the management may be true, I do not wish to discuss that. Imagine that there are no PHBs, it’s easy when you try :-). Let’s focus on engineering implementation and engineering use aspects of the idea, not on “how do we convince the suit-in-chief to buy the product” bit. Come to think of it, suits do buy some sophisticated computer tools to help their developers. Often enough they even go overboard, paying too much to get too little.

It sounds like you think developing a report in CR lite, and then recoding it in CR is faster than just coding it in CR in the first place. In both cases you have navigated through the CR UI and coded everything that needed to get coded, plus with CR lite you also coded it for that system.

Unless you have a converter from CR Lite to CR it’s going to be pretty hard to gain anything and most likely you will actually lose time.

Are you doing this out of intellectual interest? Are you planning to develop this software for your own personal fun? If so, then do so, and the justifications are found from the premise.

If not, then the business use case must dictate whether or not there is a need for this software, so “just using another off the shelf tool” is extremely valid response. Since you have not fully framed the discussion, I’m free to go in the directions I think it should go. Opening a thread does not give you dictatorial control of its direction and I have not said anything so off topic as to violate the spirit of the message board as a medium.

As for your response to my first question, your long diatribe about how you shouldn’t have to restate things isn’t something you should have said to me. My first post specifically said that if you created a tool that just spit out an output which you then manually input into CR I’m not sure how it could do so since much of CR is managed through a GUI. Would it also print out detailed step by step point and click directions? What about the fact that the GUI may be customized, certain menus may be hidden on that user’s installation? Don’t talk to me about just typing something in when that isn’t how the software works, unless you want to talk about some fictional version of Crystal Reports which does not exist.

Martin Hyde, I plan to discuss this idea, for my intellectual interest, with those people who are willing to discuss it with me here in SDMB. Whether or not you are one of them, that’s up to you to decide :slight_smile: .There is no need to call my detailed, carefully worded writings a “diatribe” either, because that does not contribute to a polite and friendly discussion.

Like I already said, I am aware of the fact that inputting stuff into CR is done through a GUI. But it is my contention that inputting a fully working and debugged report into CR, even through a GUI, is much better than using CR GUI to create and debug report from scratch.

CRLR user interface may hypothetically give you some context aware advice about what to put in where in CR interface. Nevertheless, I am assuming familiarity with CR on the part of the guy doing the input work.

In the extreme case, again, this is a matter of comparing “make and debug new report in CR the old way” and “input a fully working/debugged report into CR based on precise instructions from fairy godmother who has already magically created the report”. The latter sounds a lot easier to me.

In the more realistic case (where fairy godmother does not exist or else charges excessively high consulting fees) it is a matter of developing the report in CRLR which, hypothetically, is so much more a productive environment for reasons I will not restate here but you are free to argue with :slight_smile: and then using that. I.e. in this case “you + CRLR” serve as an imperfect implementation for “fairy godmother”.

I guess it depends on the compatibility and the price. Basically you’d be developing a faux report engine with most of the drawbacks of CR, fewer of the advantages, no primary support and still requires a CR license. Potentially you know something special about how content is pasted in CR, which seems to be a primary requirement.

Myself I’d currently recommend Stimulsoft Reports. I’ve used CR many many years ago, and thought the WYSIWYG was good for the time, but wasn’t super impressed. Our latest unfortunate encounter with it came after purchasing the codebase for a medium-size software product that included a CR admin report. We’ll probably replace it with a Stimulsoft report, since it doesn’t currently work and is impossibly annoying to debug. (We actually suspect that the previous dev team installed visual studio on the dev box, and was running monthly reports in design-mode). :smack:

For other reporting engines, I can say that Borland’s Report Builder was simple but effective, and that Microsoft’s ReportViewer is the worst one ever.

Anyway, back to the question…
[li]What’s the market for this? I think smaller companies like the one I work for managed to avoid the CR trap, and only deal with it for maintenance contracts. Larger ones might want their employees to take a CR course or something, rather than take a non-vendor supported shortcut.[/li][li]I believe CR is embedded in VS for design purposes. Is this new engine also going to support such behaviour? If so, it’ll have to support DB connectivity, business object import, etc. That sounds hard. :dubious:[/li][li]Is there a reason you’re avoiding reverse-engineering the CR report format for export purposes? If you’re only exporting (rather than importing), it doesn’t seem like that much more of a problem.[/li][li]We’ve run in to compatibility problems where version 8.x reports don’t work with the version 7.x designer. I’d imagine your app would likely have similar ones.[/li][/ul]

Although I’ve used about 957 different report writers, I have never used CR. But I’m confused about this “debugging” - what exactly is there to “debug” in a report writer? I’ve rarely done things in a report writer that I would consider “debugging”, maybe shifting the layout around, maybe I grouped on the wrong field, but generally it doesn’t rise to the level of what I am used to calling debugging. Any examples?

Nanoda, thanks for an extended reply.

ok, so I guess on this point you agree with the “CR guy sucks” guy I have quoted.

RE maintenance, whether or not something like that can be adapted to improve maintaining existing reports is a good question. Apparently not directly - after all, the “light, restricted” aspect implies that a real CR report may use some feature that does not appear in CRLR even if it could also be implemented without it (since our CRLR is “sufficient” but not full clone). Indeed, given that critics describe CR interface as being making it overly hard to locate relevant info, the “clone CR report in CRLR” (or in any other framework) without an underlying spec may be an inherently hard job because “how do I know I really cloned it?”

But on the other hand maybe it many of the “change existing report” problems could be redefined as “make a new, smaller report and then paste it into a larger old one, deleting some of its components”. Or maybe many other such problems could be easily solved by recoding-while-modifying the original report from scratch based on its spec, assuming that spec is sufficient and that the original report did not manage to deviate from that spec sufficiently. The latter case, of course, may sound no different from just throwing CR out and converting to DevExpress instead of to CRLR => CR - but we are assuming the client is demanding CR output.

Well, and regardless, even if there is no sane way to maintain existing CR reports using CRLR, maybe it would still be useful for those who want to create new CR reports. Do people out there actually create new CR reports nowadays from scratch? Or do they only maintain legacy ones while writing new ones in other frameworks?

RE “taking a course” - is there really a course that can make an environment with impossibly hard debugging significantly easier to use? I know that no amount of courses could make C reasonably easy to work in compared to Java or else to “C + memory debugger” combination. I.e. use of Java or of memory debugger is just inherently more powerful and easy, regardless of how expert you are in the “C framework” because of C’s inherent nonessential complexity. Perhaps the same applies to CR’s inherent nonessential complexity? I mean, hey, at least pure C can be debugged by logging to text file, which seems to be more than you can say about CR :slight_smile:

RE VS embedding, I have not dealt with it (probably used an older version). You mention having to support “business objects” - so basically that adds some additional features to the necessary minimum set that constitute a credible CRLR, right?

RE exporting to CR, I am just clueless on the issue. Does BusinessObjects allow people to do that? Or do people know how to do that regardless? If it’s doable then, hey, that certainly sounds like a very sensible thing to do. In fact, if it’s doable, then it sounds like CR designer itself is not even needed and can be replaced with alternatives such as CRLR. Perhaps we should then hear about existing of such competing designers for CR format? Is anybody selling such? Or let’s say “no” because that would violate BusinessObjects license and so maybe the export bit is not feasible for purely legal reasons?

RE versions, well, if the version change affects features included in CRLR then presumably CRLR would also need to be updated. Good point.

another thought. The guy I quoted above claims that there is no way to troubleshoot/debug CR. I read this, believed this and started coming up with the whole hypothetical CRLR thingie as a solution.

Now, could it be that this guy just does not realize that it is possible (maybe really hard, but still possible) to use some aspect of CR scripting to get sufficient info for troubleshooting? Because if so, maybe it would more sense to build tools that would help a user use this hypothetical scripting approach. Or, maybe such a scripting based tool could exist parallel to CRLR, i.e. yet another system created as a bandaid solution to help people stuck with CR suckiness.

I guess the question I ask in this post is excessively vague (scripting can tell us some things but not others, duh). But perhaps it would be the case that a CR guru would have plenty of experience specifically using scripting in troubleshooting complex problems that have vexed and stumped CR non-gurus he has met. If so, that would be proof that my hypothesis here is close to truth. If, by contrast, CR gurus don’t use scripting but instead use deep meditation, staring at goats-err-CR-reports and whatever other techniques that are not really reducible to a step-by-step methodology, then presumably the scripting approach would not fly for most cases.