|We do not support the use of an error handler, other than the default
one provided by FoxWeb. The default FoxWeb error handler does not only
log the error, but makes sure to clean up the environment and prepare
the channel for the next request.|
What's the reason for using your own handler? Is it to change the display of errors in the browser window? You can do so with the FoxWeb error handler. Moreover, you can add your own logging code if you are 100% sure that it is completely free of bugs. If VFP encounters an error during execution of error handler code, it pops up a dialog box and waits for user input, which in this case would cause the channel to hang.
If the problem occurs when you run FoxWeb as a regular application, but not when you run it as a service, then it's probably a user-rights issue. Make sure that the user that you are logged into the system with while running FoxWeb as a regular application has sufficient rights.
Sent by Low Vato on 11/21/2006 01:22:49 PM:
It does not seem to happen when running as a service
Sent by Low Vato on 11/21/2006 12:14:45 PM:
We have our own error handler that dumps the errors for us. It is in our code, it's just that when we get such and error (or others I think) FoxWeb seems to get totally unusable. By "variable mismatch error" I just mean the standard foxpro error, just a type mismatch, I think other fatal errors do it as well. Stopping foxweb and then restarting the web service does not seem to help.
Sent by FoxWeb Support on 11/17/2006 05:28:05 PM:
What exactly do you mean by "variable mismatch error"? Is this error generated by one of your scripts? Is it logged in the FoxWeb error log, the Windows Event Log, fwstart.log, or do you see it in your browser after you make a request?
Also, can you reproduce the error? Please send us screen-shots via email.
Sent by Low Vato on 11/16/2006 09:43:28 AM:
Thanks for the reply,
When the problem happens it does not even seem to hit the script. We are almost exclusively using the CGI program and not the *.fwx pages - 1.x compatibility is on.
Here are my settings
hide windows off
close tables on
user runtime dll off
log script errors on
1.x comp on
restart channels on
run as service off
buffer output off
session support on
full paths in urls off
keep prg files on
reset after error on
compile is on
system info on
error log on
run vfp code on
Since we have client data in our testing environment and it takes and act of god to get outside firms access to any internal resource I cannot give you access to the website.
Sent by FoxWeb Support on 11/15/2006 06:03:41 PM:
I have some additional questions regarding the problem:
Does the problem start occurring as soon as you launch FoxWeb, or does it start after a while (for example, after you get a variable mismatch error)? From your description, I assume that FoxWeb works OK for a while, before the problem starts to occur.
Once the problem starts, does it occur consistently on every request, or is it intermittent? Does the problem go away when you restart FoxWeb? What about if you restart IIS? You can restart IIS by running IISRESET.EXE from Start/Run.
Do you see anything interesting in the Windows Event Log? What about the FoxWeb Error Log, or fwstart.log?
Would it be at all possible to connect to your server for some additional troubleshooting?
Sent by Low Vato on 11/15/2006 01:05:23 PM:
I keep getting the following error:
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are:
This happens for all urls, even if i just try to hit the foxweb.exe alone or the admin page. No urls work and all of them show this same message. This seems to happen after a variable mismatch error.
We are evaluating ver 3.5 for applications that have been running on 1.2. This instance is running on xp pro sp2, 2GB ram IIS 5? Last time I got it to run again I had to restart my machine.