Date:  03/20/2015 11:04:40 AM Msg ID:  004786
From:  Ali Koumaiha Thread:  004784
Subject:  Re: trapping error 0
Wild thought:
What happen if you have a script that does this:
 
<%
select ScriptTable
Locate
lcScript = ScriptTable.Script && Memo field that contains the script
%>
Your html here...
<%lcScript%>
 
so in essense, if you update the table, the script is compiled, and will just dynamically run the scripts from a table.
 
I didn't test it, im thinking this might work?
 
 
 
Sent by FoxWeb Support on 03/16/2015 11:39:54 AM:
FoxWeb does not access the requested script until after fw_enter is called, so if you redirect properly, the script will not be touched during that request. 
 
It seems that the script is locked by multiple channels for a little while (at least a minute according to your message). After you modify it and try to access it, you will continue to get this error until all channels have released it.
 
Does the script take a long time to execute? If yes, you will need to intercept calls for a longer period. This will be no different from doing nothing while waiting for channels to release it, but at least your users will get a more helpful message. 
 
Another possibility is that the script contains a class definition or function library, which would force channels to hold a lock on it. If this is the case, then what's happening is that you will continue to get errors until all channels have received errors or timed out and got restarted. The solution to this issue is a little more complicated. You could simply update the script and restart FoxWeb, but this would cause a brief interruption. You could also have channels release the resources defined in the script after each request, but this may have slight performance implications. 
 
FoxWeb Support Team
support@foxweb.com email
Sent by Steve Moore on 03/14/2015 12:55:06 PM:
I occasionally need to update a script that is being constantly accessed. I get error 0 - Invalid script or nonexistant for a minute, presumably while the file is being re-written and compiled.
 
I tried trapping this error in fw_enter by rerouting the path to a maintenance script. However, although the reroute takes place as expected, it doesn't stop the errors. 
 
Does this error happen before fw_enter?
 
Unfortunately doing a remap at the IIS side doesn't really make sense for only 2-3 seconds at a time. Not even sure how I could do that programatically...
 
Any thoughts?