>>>>>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.
>
>Hi Erik:
>This does deal with the FORM's hardcoded paths, because with this code
>the path is set where ever you want it to be. Also, you do not have to worry about having COMPETENT users, because your users or the person that installs
>sets the path only once. With the code I gave you, setting the path is a menu
>option and is easy to use and its is always there incase the path changes.
>You do not want a program to set the path after the initial install because you have the code I gave you. Look at the code again and try to set up a test situation. It works and solves the problem of getting a path set to the a network drive. HTH :)

I think that you have misunderstood my point. SETing PATH does indeed make the program aware of all directories that it may look for programs, files, etc. But this does not even address the issue of the database location being hardcoded into the properties of the cursors in a form's DE. These paths must be set dynamically if an app is going to be agile enough to be able to use data in different locations. Simply SETing PATH doesn't do the trick. If you'll notice, the database property of a cursor contains the entire explicit path to the database, and this cannot be changed at design time, because it was put there when you chose the table from the tables list when you created the DE. BTW- if ther eis a menu option to change the path, you had better believe that it won't be set just once, no matter if that's what you intended or not. If you give a user the opportunity to screw something up, he will. 'Just when you make everything foolproof, along comes a new and improved fool'.