Spencer,

Though it may sound too stupid to be true, my findings are as follows :

Once you upgrade from VFP6 to VFP7 (my experience is from 5 to 6), the latest version will extend your classes with new properties and methods. This is logic by itself, because there just ARE more properties and methods in the newer version. However, one can wonder how this is dealt with internally;

I would say if the new properties (etc.) are not used, nothing will change the class and you can use it under 6 again. However, what may cause the new props to be "used" after all ? IMO just editing a normal (in 6) existing one, may amend the whole structure -and- depending on what you edit.
Maybe there is no general rule to this, but I'm fairly sure that when you edit an object which is drawn from another (higher), this may give some complications in the VCX. Browsing the VCX will show the abnomalies, though it may be an extensive job depening on how large the VCX is.

Of course this only applies to VCX files just being there, and not for classes created at runtime.

Anyhow, some two years ago I tried to upgrade from 5 to 6, and the whole app was a mess; up till now I never started to find out why and left this for VFP7, which box is besides me, waiting for this stupid task to perform.
Because there are not too many of these posts, it must be something specific causing it, and I guess you have it.
Note that -of course- your problem might be custom property (etc.) names in 6, now being formal-VFP in 7. I just don't know what happens with that (okay, things will go wrong in 7) with the respect to going back to 6. IMO this just MUST go wrong...

Peter





>One additional thought...
>
>If no one is aware of any obvious issues when testing/editing in VFP 7 to be run under VFP 6 my issue may simply be that VFP 7 is more stable than 6.
>
>I say this because I noticed yesterday that a change in the modal form's INIT method that SCANned through the cursor did not reposition the record pointer correctly. This caused a C0000005 crash in VFP 6.
>
>VFP 7, however, did not crash but gave a "Record is in use by another user" error and closed the form. Correctly repositioning the cursor's record pointer fixed the problem, at least in VFP 7.
>
>My though is that perhaps this, or some very recent change in my code, is just handled more robustly by VFP 7.