Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Portability
Message
From
17/11/1998 14:20:47
 
 
General information
Forum:
Visual FoxPro
Category:
Other
Title:
Miscellaneous
Thread ID:
00158389
Message ID:
00158398
Views:
16
>I'm getting to the point in my app that it's time to push it out of the nest. But I'm having a devil of a time getting it to fly outside my development directory.
>
>Here's what I want to do:
>
>The .exe and some files that I want to stay local are on the local hard drive. The data files can be wherever the user wants them (usually the server). Our clients have multiple operations, and that requires seperate data used by the same exe and the ability to switch between them. So I have it set up so that there are subdirectories off the main data directory. The main data dir just contains some setup files. Each operation will have it's own subdir with it's own database. The databases are all named "tripsoft". In the program, when the user switches operations, I want to set the database to the one in the corresponding directory. If possible, I want to avoid having to change the default dir to that subdir.
>
>The problem is that VFP hardcodes the path to all the data. Even if I do "SET DATABASE TO c:\tripsoft\data\test\tripsoft.dbc", it wants the database to be in my development dir.
>
>I thought I could fix that by going into the .SCX and taking out the path. Now it won't use the database even if I physically change the directory to the subdir. That's no good.
>
>I've noticed that if I cd to the subdir, and it can't find the hardcoded dir, it will use the one in the current dir. But I don't want to change the dir because that'll mess up all my relative paths.
>
>Is there some way to make this work? Or is there a different way of doing it that would work better?
>
>Thanks,
>
>-Michelle

Firstly, having open few databases with the same name, you take chances to mess your views (if you use some) even if you will reset database properly. Tables can be handled safely, if you programmatically reset all Cursor.Database properties in DataEnvironment.BeforeOpenTables event.
Edward Pikman
Independent Consultant
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform