Depends on how you open data.
I'd think you're opening tables by using data environments. Then no matter if you set a different path or not, the members in the dataenvironment point to the database you used during development. A solution then is to use the code by mjcmkrsr to change all dataenvironment members - AMEMBERS( laCursors, THISFORM.DATAENVIRONMENT, 1) - and let them point to your configured path.
That shows you one bad side of the dataenvironment. Even if you didn't intended, you're having hardcoded paths by using it. You're on the right track using a config file to be able to switch to other folders. There's a mechanism of VFP for finding data, if it's not in the place stored in the dataenvironment members: VFP searches along all paths given by SET PATH, additional to the current directory set by CD or SET DEFAULT. Mike has addressed using that. Still your dataenvironment members may find the path encoded in them first, and won't switch to other data.
The solution is to have a third place for the data during development. A copy of the data only local on your computer. Then you may rename that main folder, eg preceding a ~ or _, if you don't want the dataenvironment tables to find their original place and want to switch away from development data to test or prod data. Of course you may also unmap a drive of dev data or switch to a different windows account not having access to dev database or even sitch computers.
The best solution anyway, would be to open data programmatically, not using the dataenvironment. You have OPEN DATABASE, where you can specify precisely the database you want. And after that all USE databasename!tablename will open tables from that database. You can even open two databases in different paths with same name, but the addressing with databasename!tablename then obviously is ambiguous. There's a solution to that, too: SET DATABASE ("full path to a dbc here") sets a specific database active, all USE tablename (without a dbf extension) after that use tables from that database.
Generally just switch between TEST and PROD at application start, perhaps even display the current data scope, especially if the scope is TEST, so no user later accidentally works in the test database with their work time wasted, as it's not going into production data, is based on most probably older data etc.
My recommendation:
Set up three databases/locations:
PROD: Available to end users, maybe even disallow access from your windows account (if you develop as internal employee of the company), have a separate windows account,
so you can't accidentally work in production, while you only wanted to test.
TEST: Available to you and a set of users willing to beta test software.
DEV: Available only to you, maybe local, not available to any beta testers or end users. You can test your newest development here. Make whatever manual changes, but leave the test database as is, until you have a new release. The test database then can even be used for testing database updates. Of course you can repeat tests after copying PROD to TEST, only applying updates to PROD, when the update of TEST succeeds. Write scripts or use tools generating scripts from dbc differences.
Set up appropriate windows account groups and users can only find the data they are allowed to use anyway. You only need to be cautious to beta testers using TEST data when testing and PROD data otherwise. It's easiest, if you only specify what data to use at application start, don't switch forth and back.
Bye, Olaf.
Sample setup:
DEV data in C:\dev\appname\databasename.dbc
TEST data in \\shared\test\appname\databasename.dbc
PROD data in \\shared\prod\appname\databasename.dbc
Add tables from C:\dev\appname\databasename.dbc to your dataenvironemnts, then only your usage of the application will use DEV data. For all other users the initial attempt of the dataenvironment always fails and VFP will search along SET PATH, so at start do what Mike suggested. I'd put it this way, only slightly simpliifed:
Code:
* First, set the default directory to that of the executable program
SET DEFAULT TO JUSTPATH(SYS(16))
* Read the text file
lcPath = FILETOSTR("Config.CFG")
IF NOT ADIR(laDummyArray,AddBS(lcPath)+"yourdatabase.dbc")=1
Messagebox("The configuration is wrong, no database found")
ENDIF
* lcPath contains the path to the required database (without dbc file name).
* Add it to the search path
SET PATH TO (lcPath) ADDITIVE
CONFIG.CFG now needs to be in the EXE folder having either \\shared\test\appname\ or \\shared\prod\appname\ or C:\dev\appname\ as it's text
Now the only problem is, even if YOU as the developer put in \\shared\test\appname\ into your config, your forms dataenvironments still open data from C:\dev\appname\, as it's hardcoded in the dataenvironment. So either you temporarily rename your dev database path to C:\dev\~appname\ or you switchto an account not having access to c:\dev folder, or change computer, or ... many thinkable solutions.
Using the code of mjcmkrsr to change paths of all dataenvironemnt members may even be faster, as there is no timeout in not finding a folder, but it's more complicated to get going with your config, then simply SET PATH.
Reasoning for this complexity is, the dataenvironments are meant for easy and fast development, VFP is more fit for single user development anyway, though it has a comprehensive help chapter on developing for multiple users and shared data access. Application Frameworks based on VFP often have their own classes for data access not based on the forms dataenvironment. You also don't have the dataenvironment in form classes of VCXes, it only exists in SCX forms.
Bye, Olaf.
