>Hi Experts
>
>Despite having worked with FP for nigh on 10 years, pathing has always remained a mystery to me.
>
>A new system requirement is for the creation of and access to alternative database(s) wherever the user may wish to create them: local drive, floppy or network. I have a form whereby the user can browse for and select a default "system" folder. My databases reside in 3 sub-folders below this.
>
>Having selected the alternative, "personal work area" (sic) folder, the code successfully destroys my path and builds up a new path to the alternative folder, and the db folders below it.
>
>Now this is all at log on time, and as yet, no DBCs have been opened or set. As the system doesn't know what sub-system it is yet to go in, there's no point in opening a DBC.
>
>As you know, when you add a table to the DE of a form, its DBC and path to it are "hard-coded" in the the property sheet and (AFAIK) there's no way of changing this.
>
>OK, I open a form and modify some data, assuming that, as there's no path set to the "original" data, only the data within the new path will get changed. Not so! the data in the table whose path is hard-coded in the form gets changed. If necessary, I have opened the approp. DBC, but don't include any path in the open database command.
>
>To add insult to injury, when I log out, the user rec in the "remote" System Users table (which is a free table) gets flagged as logged out while that in the !"home" table gets left as logged in (with problems next time at log on).
>
>I realise I could probably include a path in the open database command but this would require my visiting a myriad of forms and changing the code.
>
>Is there a way of getting round this?
>
>TIA
>
>Terry

Terry,
You can change the hardcoded path in DE before tables are used. I think you're using private datasessions as I do. A form's DE might use a different data in developer box and in production, if hardcoded paths are not changed, and the developer path is not renamed (or moved) then that of what's in set path.

Here is the simple workaround I use (and with this I can both use testdata folder for testing and data folder for developer dbc\tables) :

*DE.BeforeOpenTables
UpdateDE(this)

*UpdateDE.prg
Lparameters toDE
Do setups && Some common code for set
Local Array aDEMembers[1]
Local lnMembers,ix,lcMembers
Public oApp
If !(Type('oApp')='O' And !Isnull(oApp))
    oApp = Newobject('myApp','myAppClass.prg')
Endif
lnMembers = Amembers(aDEMembers,toDE,2)
For ix=1 To m.lnMembers
    With Evaluate('toDe.'+aDEMembers[m.ix])
        If Lower(.BaseClass) == 'cursor' ;
                and Atc(oApp.cAppDBC,.Database) > 0
            .Database = Addbs(oApp.cAppDataPath)+oApp.cAppDBC
        Endif
    Endwith
Endfor


*myAppClass.prg
Define Class myApp As Custom
    cAppDBC = 'myDBC.dbc'
    cAppDataPath=Sys(5)+Curdir()+'data'
    cCurPath = ''
    Procedure Init
        This.cCurPath = Set('path')
        * Code getting production data path here - lcUserDataPath
        This.cAppDataPath = arrDataLoc
        Set Path To (m.lcUserDataPath+';'+This.cCurPath)
    Endproc
    Procedure Destroy
        Set Path To (This.cCurPath)
    Endproc
Enddefine

With this code I simply run any form. It uses testdata folder pointed. When I'm done all I do is :
clear all
to restore my development 'data' folder and paths.
PS: Do not try to do this in form.Load, it fires too late.
Cetin