Hi Diane,

>I've been asking myself the same question as Ravi. I have all those VFP reports (over 200) all using cursors prepared in a prg or a frm before calling the report itself (no dtaenvironment in the reports).

>I wonder what is the easiest way to convert all those reports into Crystal. If I understand your answer correctly, it means I have to create new empty tables for each of my report in order to link them to Crystal?

Well, the easiest of course is to copy the results of the cursor to a FOX2X table and use that for reporting in crystal, and build the reports GUI from scratch.

>I've also been ask to evaluate the time to do that conversion, if you have any experience, would 2 hours per report seems fair to you? Assuming I know only the basic of Crystal from examples in another app, I'll learn along the way.

As Craig says, it really depends on the complexity of the report. There are a few things that are easier with VFP reports than crystal. Printing pictures is one of them. Overall, Crystal is a far more powerfull reportwriter than the VFP one. Even if you'll compare with the new VFP report writer in VFP 9.0, Crystal is far more advanced. However integrating crystal into your VFP project is not that easy if you want to do it well, and distribution of the runtimes for crystal is also one to consider (DLL hell).

The decision to wait for VFP 9.0 or to go for Crystal Reports IMO depends on the value of having sophisticated reports. If you're building an in house application, VFP reports might be adequate, if you're selling commercially, crystal indeed might show more professional.

Personally I've choosen crystal about 5 or 6 years ago. I've build supporting classes to handle crystal reports as easy as you do with VFP reports. Making a crystal reports generally does not take more time to do than VFP reports. For me the choice was an easy one. I had to deliver commercial applications with graphs and subreports, something rather impossible with VFP reports.

Walter,