Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Understanding VFP internals
Message
From
21/11/2001 05:55:30
 
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00584014
Message ID:
00584358
Views:
30
This message has been marked as a message which has helped to the initial question of the thread.
>>>Jim,
>>>
>>>Leaving aside the fact, that whole complicated code is already written based on ALTER TABLE, how can I do this process for DBC's tables?
>>
>>Run GENDBC to get all the code you need to create the table, PK, FKs, RI, indexes, etc. Store all that in a metadata table. After you create the replacement table, drop the original table from the DBC, move the new table over, rename it. You would then need to add the new table to the DBC and run the code to replace all this info back in the DBC.
>>
>
>Yes, this is very complicated...
>

Only if you make it so; several people have already pointed you in the correct directions - spawn the process fresh with API_APPRUN with it's own, separate and distinct config file, or use a launcher to manage the CONFIG.FPW for the environment (what i do; my launcher, not written in VFP, examines a set of key resources based on information in the registry related to the local workstation and userid context, constructs a custom CONFIG.FPW with an arbitrary name, adjusts the environment variable FOXPROWCFG to point to the temporary file name and spawns a fresh process with the VFP executable, inheriting the custom-constructed CONFIG file through it's altered DOS environment variable set, which I'm careful not to inherit into other execution contexts. This cleans up all sorts of issues, but involves a bit of non-trivial code to do. You can accomplish most of the same functionality by not including a CONFIG.FPW in the compiled executable or the startup directory used to initiate the app and add the -C command line switch to the launched/spawned command line on a case-by-case basis.

>>IMHO, this is a total mess when a simple [to me at least] solution is to just start your JobControl with the settings you need in a CONFIG.FPW.
>>
>
>Here is the problem: for most operations we need to use user's configuration. Only for this particular application I need to change temp dir to something else.
>

Then launch that externally (if necessary, synchronously using the LaunchAppAndWait() method of API_APPRUN) with it's own unique config file specified.

>
>>As for your reply back to me, I can not find anywhere a function that returns the setting for SORTWORK, EDITWORK and PROGWORK. The only function is SYS(2023) for TMPFILES.
>
>
>Yes, and that's unfortunate... Of course, I can parse Config.fpw file to find them, but it's not an easy solution. SYS would be so much easier...

Parsing an embedded CONFIG file. or one whose value is inherited from a command line switch or the environment variable is not necessarily trivial.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform