The three problems seen most here were:

1) LOCAL statement requires commas between items when multiple items named.
BAD: LOCAL memvar1 memvar2 memvar3
OK: LOCAL memvar1, memvar2, memvar3

2) SQL statement using GROUP BY that did not comply to ANSI syntax - which was very common in VFP until V8 - failed with syntax error. On these you have 2 options:
a) fix it to comply as required;
b) Use the new SET ENGINEBEHAVIOR 70 command to invoke the old VFP7 SQL engine.

3) "Corrupted table" (or something similar) might be reported yet the table would work when re-tried with VFP6 or 7.
VFP8 added some checking to trap a bad situation and generate an error while prior releases did not setect the condition and continued to run.
You can (NOT recommended) use the new SET TABLEVALIDATE TO 0 command to get around this problem (0 turns checking OFF and default is 3 (check)) or you can try to invrestigate the source of the problem and fix it. Unfortunately investigation is often non-productive.

There were other issues, the more 'dangerous' relating to going back to V6 from either V7 or V8, but I assume they don't apply.

good luck. WELL WORTH THE UPGRADE! And though I'll bet that Intellisense will frustrate you and have you wanting to turn it off, you should try to learn to live with it as it comes in REAL HANDY over and over again.


>I'm sure this has been covered before but when I upgraded from VFP4 to 6 I had to fix a few things in my stuff (projects/forms/etc.)
>
>Does anyone know if upgrading from VFP6 to 8 is cleaner? Did anyone find out conversion issues initially with their work or even get supprised down the road?
>
>Regards,
>Torrey