>I designed a package specific to the users data. There are 400 sites each having their own data maintained at a central location. They are sent on a periodic basis THEIR data which I put in one subdirectory of the program '\DATA'
>
>The software was built from the ground up with this intent.
>
>I have several sites that want to share the same computer but they would need different database containers pulled from the home office - still needing to reside in '\DATA' subdir.
>
>They must login w/name and password where I also keep their unique site number.
>
>If I were to put their data in directory say '\DATA101' and '\DATA102' then when they login - rename the directory to '\DATA' that belongs to that site?
>
>This sounds scary - but maybe its not???
>
>Right now the path for '\DATA' is in the config.fpw code but this gets compiled in the code and executes when the user clicks on the .exe (I think thats whats happens?) There are references throughout the program (lots of code) 'data\member.dbf' so I feel it necessary to keep the .dbc in the '\DATA' subdirectory.
>
>Are there any thoughts? Is this safe as long as I check the current site in the \data directory, rename it then rename the proper one to '\DATA'?
>
>
>Robert

Basically, the only place where VFP cares about datapaths (unless you specifically hardcoded it) is DataEnvironment.Cursor.Database property for dbc tables, and DataEnvironment.Cursor.CursorSource property for free tables. Therefore, it's enough to keep real datapath as configuration setting, automatically/manually update it when app starts and fire code in Form.DE.BeforeOpenTables events to reset Cursor.Database/CursorSource properties.