Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
FoxWeb Question
Message
General information
Forum:
Visual FoxPro
Category:
Internet applications
Title:
Miscellaneous
Thread ID:
00413129
Message ID:
00413386
Views:
23
David,

Well, you make this sound like it's not indigenous to FoxWeb. So, I'm assuming that switching to WebConnection or another product will not fix this. This is a crying shame since VFP takes the longest opening files.

What happens if I build a VFP COM object that takes requests from the FoxWeb stuff. The COM object could hold the tables open couldn't it? Then just do queries and pass back results. Whaddaya think?

Thanks again for your help,

>Curtis,
>
>>Every time a program is kicked off it (apparently) has to re-open any tables that are involved and re-set the environment. If, for instance, the user is performing some commands against a complicated view that takes 3 seconds to open he's going to have to wait a minimum of 3 seconds every time he clicks a Submit button before he gets his answer back.
>>
>>Is there a way around this? How can I keep any tables/views open between submissions from the user?
>
>You're face to face with stateless programming, which is the nature of the web. Between the time your user clicks a couple of submit buttons, some other user(s) could also be hitting the web server with other requests, which would change your environment of open tables, views, record pointers, etc....
>
>About the only ways around it involve tracking state somehow, using a cookie or id embedded in the URL, and then restoring state on the server side. You might, for instance, create a temporary view that remains open on the server with a name that is tied to the user's session id, and then time them out and close them down after a certain period of time (hoping you don't run out of server resources first). Probably not a good approach on a heavily-used site. Or you could persist certain data, such as the user's last query parameters into a session variable or an XML snippet, then grab it again on the next hit, or save the view result into a temp table (if sizes are small) that is tied to the session id, then reopen the temp table on the next hit. Then periodically clean out the old temp files.
>
>That's the kind of hoops you'll have to jump thru to get around the current situation, which may not be so bad after all...
-cjh
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform