hi Walter,

Please excuse the length of time it has taken for me to get back to UT and reply to your message. I did see it, some time ago, while Colin and I were still travelling.

Since then I have more-or-less forbidden myself to spend time on UT for any reason while I re-acquainted myself with my family after an arduous two years on this project and took care of some other, pressing deadlines <s>.

I put off replying to your message partly out of sheer exhaustion at that time but also, I admit, because it is depressing to have to give answers you probably won't like <s>.

But... I'm back on UT, briefly, this week, and you do deserve a response. So, here goes, better later than never, I hope <g>.

First, let me say that I appreciate all your thoughts and the amount of consideration you have given to these questions. But (here is the part I know you won't like) I don't want to debate the relative merits of individual features in Crystal Reports and VFP RW with you.

I tried to tell you this when we visited your user group: Crystal Reports and VFP RW try to accomplish two different things for two different target sets of users. The reporting design work in this version of VFP was in NO WAY aimed at satisfying the same requirements as Crystal Reports satisfies, so a point-for-point comparison doesn't really make sense.

I realize that this fact makes it awkward for you to make a simple choice between the two reporting styles when you're trying to make such a choice when building a specific application. But that doesn't change anything. It is still a fact.

Yes, I realize that it would be nice to allow users to create simple designs in the VFP design surface and then migrate the reports to Crystal programmatically. You *can* actually do this -- and you can use a lot of the underlying ReportBuilder technology as well as the VFP-Reporting RDL to help you do it -- but there is an admitted impedence mismatch, because we were not aiming to be "just like" Crystal Reports or "as good as" Crystal Reports.

This is what I told you at the meeting, and it is really true.

Suppose, for the sake of argument, we had worked on the RW with the idea of being "as good as" something else, or fulfilling the same requirements as something else. Crystal Reports would probably not have been the model we chose.

For strategic value, it would have made more sense to move the RW in a direction that would facilitate migration to SQL Server Reporting Services, not Crystal Reports!

For ease of use, an appropriate design surface for end users as well as a document-visualization model that would appeal to FoxPro developers (plus a fully-realized XML description language), and the proper level of integration into a database-centric IDE, the best model I've ever seen is FileMaker Pro, not Crystal Reports!

(If we had taken either direction, your impedance mismatch would actually have increased, FWIW.)

I have mentioned that VFP is a database-centric IDE. One of the reasons why Crystal would be such a bad model for us is that VFP is a full-fledged data handling environment. Many of the things that you mention that you think the RW "should" be doing are taken care of in surrounding code. Crystal really has no choice but to take care of them within the report, we have more flexible, and often more nimble, alternatives because we are an *integrated* tool.

IMHO, the fact that certain types of behavior or processing should be bound-into-the-reporting-mechanism is misconception that you have about the "best way" to do something; these things don't translate and should not be expected to.

FWIW, as a separate issue, it is also a misconception that the RW is a one-pass process; it has been two-pass since VFP 8. In 9 the ability to suppress or require the passes is completely at your command. I did show you the use of this capability in my demonstration, to provide correct "reset on group" pagetotals; perhaps you didn't realize what I was doing there. We can leverage this for pre-processing as well as extra detail bands (which, yes, I also showed you in a different demo).

But the exciting thing is.... that maybe NEITHER way of doing things is the best way to preprocess -- in VFP. Try using correlated subqueries with grouping, also added in 9, and you may wonder why you even thought you should do this within the context of the report <g>.

I didn't talk much about this in my presentation, because I really have not had time to benchmark, but it is one of the most exciting output-related enhancements among the SQL improvements in VFP 9. It has the potential to blow other methods out of the water, both in flexibility and performance, and it is possible to combine these features because we are an integrated tool in a fully-featured database environment. It is simply not always best to bind everything in to the context of the report.

Some things you will have to realize: although we are an integrated tool, and although you can run lots of kinds of code in a report, the RW Engine is essentially not a data-processing engine. For example, it leaves the evaluation of functions, even the formatting of expressions, to its "sister" elements in the VFP language. It is bound by the Xbase rules of Xbase scoped commands. Although we have a lot more native data-handling technology to leverage, we can't just decide to handle data in a whole new way than this underlying/native data-handling technology.

The last paragraph is my shortest-answer-possible to "why multiple detail bands and not subreports" <g>.

Also, that paragraph is the best explanation I can give you quickly of a fundamental difference between Crystal and VFP, which I think you have critically mis-identified. The issue isn't the "number of passes". VFP does two passes, but when the preview occurs, those passes are OVER. The report is OVER. No data-manipulation is occurring in the engine (and no matter how much YOU do the engine isn't going to know about it).

By contrast, Crystal "is" the report. During the preview, Crystal is manipulating data to extrude the report, the data is live during this period. This is why you can re-order etc.

In any n-tier development scenario, or any component architecture, you eventually have to make decisions about where to put the processing load and where to do each portion of the overall job. VFP makes parts of them less expensive than Crystal and parts of them more expensive. It puts some of the output load outside the context of the reporting engine, because it has really good choices for doing that.

[FWIW ... you could probably design a VFP preview interface that included re-ordering buttons and simply re-run the report into the preview surface. This would be more processing-intensive in some ways but still less than Crystal in others.]

Where these choices are made, this isn't a case of VFP being "not as good". It's just different. I was quite serious when I said that, if VFP's RW were better, it would probably be even *less* like Crystal Reports than it is <s>.

Meanwhile, to answer one of your non-Crystal related points: performance with Xbase code in reporting is pretty darned terrific, actually. As usual, it depends on how you write it and (like Rushmore and other good things) there are rules to learn to write it efficiently.

I wouldn't (for example) add GDI+ to write every single text object in a report without an extremely good reason <g>. I'd add it to create the charts you ask about, though.

I hope this gives you at least some of the information you were looking for. If not, please realize that although I may try to be here for short periods of time I am not going to be able to have a lengthy debate about it.

>L<