>>>>Does anyone have any comments about rules for using database tables from
>>>>different directories? In this application a directory may reside on the
>>>>local PC, but the data path may be on a server, either one might have a
>>>>directory designation determined by the user.
>>>
>>>Form.DataEnvironment.BeforeOpenTable events should call app method resetting DataEnvironment.CursorX.Database properties.
>>
>>Hi Jeff:
>>In one of my vfp applications, I have a menu option that says..
>>SET DATA PATH...If you click on this option, a FORM (Called GET_DATA)
>>opens and you can set a valid data path by filling out a text field.
>>The code I use for this is in the click event of the OK button on GET_DATA.
>>HTH...thanks ...rob :)
>>if !empty(thisform.text1.value)
>> store alltrim(thisform.text1.value) to mypath
>> newpath = mypath+"\my_database_name"
>> if file(newpath+".dbc")
>> set path to &mypath
>> else
>> messagebox('Can not find Data Files from - '+mypath,'Problem')
>> thisform.text1.setfocus
>> return
>> endif
>>endif
>
>This is a good idea, but still doesn't deal with the form's hardcoded paths in the DE. I think that a combination of the two methods suggested above. Procedures allowing the end user to choose the data location should only be used with known COMPETENT users. As most of us know, this is very difficult to ascertain. A better solution would be to specify a program to run after the initial install that would prompt for the location of the data and store the result to a location table that would be accessed by the program from then on.

I currently support a number of apps. which may use data from various sources (file servers/local drives or the same file/server drive mapped
with a different letter (M,L,X) depending on the user.

Here is how I handle the situation:

Use a app.ini file to store datapaths and possible other app settings.

Upon start of the app, if app.ini already exists, open it and get the necessary datapaths and try to open one table that SHOULD always be there.
If failed to open tables, prompt the user for the datapath issuing a GETDIR() prompt and save path in app.ini file (this is
also what should happen on the first time in, or when the app.ini can't be found all together.

a) In the maim program load this datapaths(s) to a memory variable so that it is accessable from any forms call thereafter
(optionially initially a predefined property on your apps main object. Oapp.Datapath ).
b) in the before open tables on the DE or the load prodedure call a routine which uses this path and resets
the recordsource (now using this path) for all applicable files.


IF you need source code samples let me know (my source uses Window's calls to handle the app.ini sections)

Good Luck
Ricardo B. Garcia (703) 222-9775