>To Kevin and everyone else!
>
>I am building a project which is using many free tables that must remain as Fox2x type for now.
>
>I'd like to do the following:
>Build the project on my local drive using a local copy of the free tables.
>Test the project on my local drive using the real free tables on the network.
>Create an .exe and move it up to the network to run from there without the project going back to the local drive to look for the .dbc or the tables.
>Be able to switch back to a local drive copy with local tables for continued development.
>
>I have Stonefield installed in this project, but am very new with it, and don't know what Mere Mortals controls and what Stonefield controls.
>
>Other programmers here have written methods that use the addpath() function before any read events to set the network path but this solution doesn't work, perhaps because the .dbc doesn't know what's happening? The user can see the data (sometimes!) but they can't update it.
>
>Last week Kevin talked about using the Metadbc and having one record for each database, which means I'd need one dbc for each scenario? So I'd have to coordinate them and duplicate the views in all of them?

I personally had the same problem. For one project, I use an ".ini" file that contains a section for devl and one for prod. Within each section, I have listed the paths of everything I will need to access. The actual paths contain a directory called devl, and one called prod.

EX:
c:\software\devl\projects\project1
\\REMOTEMACHINE\software\prod\projects\project1
c:\data\devl\
\\REMOTEMACHINE\data\prod\

The ini file looks like this.
***********************************************************
[prod]
DATA_LOC=c:\data\devl\
SFTW_LOC=c:\software\devl\projects\project1

[devl]
DATA_LOC=\\REMOTEMACHINE\data\prod\
SFTW_LOC=\\REMOTEMACHINE\software\prod\projects\project1
***********************************************************

The first thing I do in the program, is get the drive(machine) we're running on.

machine = IIF(LEFT(SYS(5), 2) = '\\', LEFT(SYS(5), AT('\', SYS(5), 3)-1), SYS(5))

Then I check which environment(directory) the program is running in by using the following:

current_environment = IIF('prod'$SYS(5) + SYS(2003), 'prod', 'devl')

From there you can use the ini file to set up variables pointing to the proper paths.

data_path = get_ini_vars("file.ini", current_environment, "DATA_LOC")
sftw_path = get_ini_vars("file.ini", current_environment, "SFTW_LOC")

Then use the variables whenever you open a table, reference a report, etc.

USE (data_path + "tablename.dbf")

The get_ini_vars() is something I coded a long time ago to read ini files, but I think there is probably a better(different???) way. This way nothing is "hard coded" that would cause a recompilation for each environment and the program knows which database to access based on the path the program resides in.

Yes, I do have a separate database for devl and one for prod and I keep them in sync with modified versions of GENDBC/GENVIEW/GENTABLE that basically replaces every occurrance of 'devl' with 'prod' in the programs that are generated. I then run the modified programs in the production area. And voila! Depending on the parameters I pass the program, I can move everything from devl to prod and back again.

Another project I have, doesn't use the ini file, but instead sets the default path using SET PATH and the "current_environment" variable.

EX:
set_default_command = "SET PATH TO " + machine + '\software\' + current_environment + '\projects\projects1;' + machine + '\data\' + current_environment

Also, add error checking that the current environment(path) actually contains 'prod' or 'devl', to keep someone from running it where the directory structure is not set up properly.

Cheers,
Paul