The simple solution is to
SET PATH ....
Where .... is configured per customer, hos data base directory.
Because even though paths are hardcoded into the cursor objects of the dataenvironment, if VFP does not find DBFs at these paths, it searches along paths you set via SET PATH. That can also be multiple paths, you can specify many paths comma separated or SET PATH ... ADDITIVE.
In cases your customer have the same paths as you use during development, that would let your application prioritize that data, as it's found before that search mechanism is starting.
But that's the only reason your app may "open the wrong cursor at times", as you say. If that's not the case, then that's not the reason, then you'd need to find other problems, eg private datasession vs default datasession forms. initialselectedalias, autoopentables, autoclosetables,... There are many things influencing the bahaviour of data/table opening and closing.
But SET PATH to is normally sufficient, especially if you use a non standard folder for development, which doesn't exist at neither customer, like a directory you name randomly. It should best be on drive c:, as directories to other drives, mapped or not, would lead to high latency times, perhaps, if drives are searched, which don't exist. I even had a customer with CD as drive D:, whicle that was a local drive to my development machine. And whenever there was no CD in the drive of the customer, that even caused windows to ask the user to insert a CD, just because a file was searched on drive D:, which was optional.
For this and other reasons, you can make use of Dataenvironment code to alter the cursor path properties just in time before they are used and in effect. Tamar has written a routine for the "1001 Things..." Hentzenwerke book. It may suffice to mention it, if you have that book. Otherwise think about changing the Database and CursorSource properties of each Cursor object in the dataenvironment in the OpenTables method, before you DODEFAULT().
Bye, Olaf.
