>>Evan,
>>
>>Thanks for your suggestions. You gave me an idea that seems to have worked:
>>
>>When I look at the properties of the cursors in the form's Data Environment in the Development Environment, for each cursor, the database property shows the full path to the test database on the network, using a mapped drive letter, e.g. Y:\....\dbname.dbc
>>
>>So, I unmapped Y; in Windows Explorer, then started VFP and ran the form. It ran fine. When I exited it and opened it with the form designer, and looked at the cursors in the Data Environment, they now all point to the database on my local computer.
>>
>>Hmmm
>>
>>Again, thanks for your response.
>
>Jim,
>
>I never trust any of this magic stuff that VFP does "for me" in the background. I use a form class that clears out the DE in the load event an rebuilds it according to the environment variables I have set at run time. Tha way I know in dev mode I am using the dev data and in rela mode I am usig the rela data and never shall I have the worng data loaded. This si one more reason to be usng a framework that handles all of this stuff for you.

Huh, that is little bit to radical ( even for me {g} )

In my personal experience, Form.DE can be used safely by setting(fixing) DE cursors paths at run time
from Form.DE.BeforeOpenTables() method .
What I do is simply pass entire DE as object ref to global app object which does run time path construction, and then spoonfeed it back to each DE object (cursor) in a loop.

I use it happily last 10 years and it never 'fooled' me into writing to wrong set of tables. (DBCs)
Hence having multicompany/period accounting and related systems with large numbers of twin-sibbling DBCs

IMO the best thing is not using Form.DE at all. Having BO's in code (session objects in prg) , open all dbcs/tables directly
and calling forms which do not open any tables themselves (empty Form.DE). Nowdays I still deploy above described solution but only for limited number of forms which actually open their own data in private data datasessions.