Boris said:
This is backwards of what I usually want--normally if you have a
long-running ASP script, it's a good idea to check to see whether the client
is still connected so you can cancel execution.
However, I have a script that absolutely MUST finish one it's been
started--is there a way to cause the entire script to execute, even if the
client disconnects in the middle of the process? It doesn't matter if the
script returns anything to the client, but once it starts saving values to
the database I need it to finish!
Thanks for your help!
--Boris
Long-running tasks are not ASP's strength. Here's a alternative and
simple yet powerful approach for handling such tasks that I've suggested
a number of times on these forums. It's essentially a background
batch-processing system that allows submission of "jobs" from an ASP
page. Several advantages
result from separating long-running batch jobs from ASP:
a) greater interactivity for the ASP user,
b) a reduction on the load to IIS,
c) control over the number of concurrently running batch jobs, and
d) the ability to continue/restart jobs if IIS, the database or any
subsystem goes down or if a job fails (e.g., due to program error,
etc.). The result is a much more robust and flexible processing system.
Here are the 3 major pieces of such a system:
1. Job Requestor Page:
Let the ASP page request a job by adding an entry to a "job table" in
the database. The ASP page stores the necessary data (job input
parameters and user information) in the job table. Once the job is
entered into the table, the ASP page merely tells the user his/her job
is queued and exits (or redirects to the Job Monitor ASP page, below).
2. Job Scheduler:
Use a stored procedure, Windows Task Scheduler, SQL Server Agent or a
VBScript script started by the @ (AT) processor to periodically examine
the job table. If no job is currently running and a new job has been
submitted then get the input parameters for the new job from the job
table and start it. Once a job completes, the status of the job should
be marked as "complete" in the job table and a URL for the result (if
required) provided in that same table.
3. Job Monitor:
This is an ASP page that displays the status of jobs and each job's
location in the job queue. The user can display this page to determine
the status of his/her job. Once a job is complete, it's status is marked
as such in the job table along with any resultant URL (a report, a DOC
file, an HTML page or other file). The user can click on that URL to
view the result of his/her batch run.
You can add operator/user functions such as
a. terminate job,
b. put job on temporary hold (cease processing),
c. restart job (in case of system reboot, database shutdown, etc.),
d. allow a variable number of concurrent jobs to run, thus controlling
the background job load.
These require that the code for the various jobs be written in such a
manner that they cooperate with the Job Monitor program.
Good Luck,
Michael D. Kersey