>Like
>
>c:\mainprog
>c:\mainprog\fall98
>c:\mainprog\spr98
>
>& from the software itself it should change the seasons that means, suppose a
user selected spr98, all my forms, should load data from that dir...
>
Hi,
- You could use filter and/or views instead of subdirs.
- You could use subdirs as you suggested. If you use multiple dbfs then you wou
ld need only one dbc but this would need extra coding loading DE and as years p
ass many tables would be added to the same DBC.
- One DBC and one DBF method is more sense. All you need is to have a copy of t
he DBC also in subdir. In this case after user selects season you would change
your data path with *set path*. This way AppDir need not be changed.
ie:
public cOld_Path
cOld_Path = set("path") && Path without data.
..
* User selection of SEASON
set path to cOld_path + ";" + cSeasonPath
Cetin

OK, let's elaborate on this furthermore. I have a routine (in FPD only, for now) called Year.prg, which makes a subdir, and copies all the relevant tables into it (the subdir is called .\96, .\97 etc), then it copies the source of the Prog(1) into that directory and finds the Set Path statement in it, and adds two more lines to add the original app's directory to the beginning of the path, and makes a couple of other modifications to reflect the 'this is read only data for year 96' in the app title; then it compiles it and generates a batch file to call it.

Now in VFP and a .exe it should behave a bit different, probably still generating a batch file to call the .exe with a '96' as a parameter, so the app would know the directory to add to the top of its path (if necessary, i.e. if called with a parameter), so this modification would probably go into the app class. What's more interesting is the question of the DBC - I guess the best solution would be to copy the dbc itself into the subdir, since it keeps only relative paths to the belonging .dbf's.
- pros:
    it all remains contained in the .dbc the way it was
    no need to change anything big in the app
- cons:
    if the master .dbc gets changed, the .dbc's in the subdirs don't know it, needs redistribution
    what if some table is marked to be common, i.e. not belonging to a particular year, and should not be copied into a subdir; since we've opening the .dbc in the subdir, and the table is visible on the path, will it be regularly accessible from the .dbc or not?

mmm... before I run into several hours of testing, I'd like to have some opinions from you folks. Take your time after Christmas, this is no highly important issue.

TIA and have a good... whatever you like :) .Signature { margin-top: 12px; color: #666666; } .Signature a { color: #666666; }