>> In the long run you're better off re-factoring
>> the old procedural based code. Time consuming?
>> Yes! More maintainable? Absolutely!
>
>I gather as much, I'm afraid. I did a Q&D conversion from Fox 2.6 WIN into VFP 5 once, and while I eventually rewrote the whole thing, the quickie conversion clanked along until the final transition.
>
>I've seen several obvious problems with the old dBase code, most notably reports (which went out to printers in DOS), but there are a few that were stealth problems, like the fact that the previous programmer liked to write full names on his tables, like "Inventory" (9 letters) when dBase was incapable of reading beyond the first 8 characters; FoxPro kept looking for a table named "Inventory" when it was actually named "Inventor". I found about five instances like that in one program.
>
>Does anyone know of any other pitfalls or booby traps that dBase might hold?
>
>TIA.

Patrick,

First, look at the SET COMPATIBLE command. That'll assure you that what the original intentions were are carried out.

Second, as far as the reports...use the VFP report writer. Even back in FPD 2.0. along with the GENPD.APP, it made things a lot simpler. These days those old Epson/IBM escape sequences probably will do more harm than good.

Third, and connected with the above, use the VFP SQL to derive cursor to power the reports. You can create one SQL statement that can satisfy all the necessary grouping, and can just worry about modifying an existing report and saving it under a different name.