The on error will only return errors from the winhttp object - typically, about the only thing you'd see is a 404 if the url doesn't exist or some sort of code for an invalid header returned. Errors raised by the called page have to be resolved there. Anything invoked by global.asa needs to intercept errors so nothing gets to the screen. If your familiar with win client serve, it's like the difference between dcom and com - com can write to the screen, dcom, which executes on a remote machine should never do so.
The Application_OnStart subroutine can be called once a day, once a month, or once every few minutes - you don't really have any control over it.
If you're trying to run something once a day, It's more reliable if you put it in Session_OnStart and included code to check if it's been run today.
My personal preference for running scheduled events is to do it from a unix cron - use Lynx to run an asp script and route any output/errors to either a logfile or /dev/null. You can also go with 3rd-party services that will do this, but you can get a unix account with cron for $2 US/month and do it for many domains.
I usually dim and set a timestamp in the Application_OnStart event. I display it and some session count info on my homepages if the http_refferrer is my ip or something like debug=Y is passed in the url. Helps in situations like this.
WinHttp - I usually use server.XMLHTTP as it uses a reduced tcp/ip stack so it's faster . IIRC, WinHttp creates a new session - even if used locally - which may result in flakey things if used within global.asa. Might happen with Server.XMLHTTP also, but I've never really used it from an asa file.
If you want you can zip up your global.asa and the script you're trying to execute from it and pm me with them. I'll take a look at it - sometimes it's something S+S but just needs a fresh set of eyeballs to pick it up.
Edited by dpyers
Topic Options
Post Options
Thanks(0)
