Calling ASP function asynchronously

[Bob Murdoch]

I have an ASP application that calls a COM function to create a custom
report as an Excel file. This works in a synchronous fashion, as long as
the report does not take too long to create. If that happens, the session
times out and we run into other kinds of problems.

I have, in other cases, executed a stored procedure asynchronously (thanks
to a tip from this group) thru ADO.

I'm wondering if ASP provides some way of executing a function (an ASP
function, not ADO) asynchronously? I could then make the call to the COM
function from within this async thread, and implement the same refresh logic
on the client that we used in the ADO solution.

tia,

Bob M..

[J. Baute]

AFAIK there is no way to make an asynchronous call to a VBScript function,
since you can't define events in ASP, and that's something you need to be
able to know you results have return properly,

but, since you managed to work async with a stored procedure through ADO,
maybe there's a way to call the COM object from an stored proc which is
perfectly possible if you are using MS SQL server as your DB.

Btw, I'm curious how that async stored-procedure magic works in ASP though,
would you mind sharing a snippet of code? :)

"Bob Murdoch" <ra***********@erols.com> wrote in message
news:e1**************@TK2MSFTNGP10.phx.gbl...

I have an ASP application that calls a COM function to create a custom
report as an Excel file. This works in a synchronous fashion, as long as
the report does not take too long to create. If that happens, the session
times out and we run into other kinds of problems.

I have, in other cases, executed a stored procedure asynchronously (thanks
to a tip from this group) thru ADO.

I'm wondering if ASP provides some way of executing a function (an ASP
function, not ADO) asynchronously? I could then make the call to the COM
function from within this async thread, and implement the same refresh logic on the client that we used in the ADO solution.

tia,

Bob M..

[Bob Murdoch]

"J. Baute" <WU**********@spammotel.com> wrote in message
news:40*********************@news.skynet.be...

AFAIK there is no way to make an asynchronous call to a VBScript function,
since you can't define events in ASP, and that's something you need to be
able to know you results have return properly,
That's what I figured. Couldn't hurt to ask though.
but, since you managed to work async with a stored procedure through ADO,
maybe there's a way to call the COM object from an stored proc which is
perfectly possible if you are using MS SQL server as your DB.
Yech. No MS Sql Server here. I'm using Firebird. I could probably put
together a UDF to make the call, but that doesn't seem to be a proper
seperation of the data/application layers. More likely, I'll implement the
call to our middle tier in the com object, and let the middle tier create
the report.

Btw, I'm curious how that async stored-procedure magic works in ASP though, would you mind sharing a snippet of code? :)

Sure.

We've got an include file called DbLibrary.asp, which contains all of the
logic for connecting/opening datasets/disconnecting. In this library is the
function for executing an async query:

function ExecuteSqlAsync(ASQL)
{
var vCount = 0;
vDBConnection.Execute(ASQL,vCount,0x10);
}

The 0x10 flag is equivalent to the constant adAsyncExecute.

The long running process is kicked off when a user makes a change to a
pricing model. We first generate a unique id for tracking the progress of
this event, then kick off the stored procedure via the above call. We then
redirect to a generic please wait page. This page shows a message to the
user, as well as an animated progress bar. It also contains an invisible
IFRAME, whose source is a page called WaitBackground.asp.

WaitBackground contains a refresh header set to 5 seconds. Each time the
page refreshes, it checks a table to see the status of the job (keyed by the
ID mentioned above, and updated by the stored procedure). If the job status
is complete, we use client side js to do a 'parent.document.location = ',
and show whatever page the user should be taken to.

All in all, it works very well, for both the short updates (the user sees
the progress screen for just a few seconds), and for longer updates (they
still have to wait, but are entertained by the animated progress bar moving
back and forth <g>).

Bob M..

<!--#include virtual='/Shared/Server/DbLibrary.asp' -->
<%

function SaveStopRateModel(AProcessStatusId)
{
vSql =
"execute procedure inv_save_stop_rate_revision(" +
Request('revid') + "," +
AProcessStatusId + ");"
ExecuteSqlAsync(vSql);
}

ConnectDb();
var vNewId = GetNewId2('PROCESS_STATUS_GEN');
SaveStopRateModel(vNewId);
Session("ProcessStatusUrl" + vNewId) = 'StopRateEdit.asp';
Session("ProcessStatusMsg" + vNewId) = escape(
'Your changes to the stop rate model are being saved.<BR><BR>' +
'Please wait while salescheck stop rates are updated based on your
selected "Effective Date".<BR><BR>' +
'This process could take up to two minutes. You will be returned to the
stop rate editor when complete.');
Response.redirect('PleaseWait.asp?processid=' + vNewId);
%>

[J. Baute]

Thanx, and interesting piece of code to say the least,

btw,
couldn't you use a simular technique to create that Excel report?

Why not call a .vbs script from ASP by using the WScript.Shell Run() method
with the param bWaitOnReturn parameter set to False, which should just call
the VBS script and get on with the rest of the ASP code.

That way the VBS script is generating the Excel report in a seperate process
running on your webserver, and you can present the user with another one of
those fancy progressbars they like so much <g> until the report is fully
generated.

Calling a COM object from a .VBS script is practically the same as from
ASP, so I'm thinking this should work.

"Bob Murdoch" <ra***********@erols.com> wrote in message
news:O6*************@tk2msftngp13.phx.gbl...

"J. Baute" <WU**********@spammotel.com> wrote in message
news:40*********************@news.skynet.be...

AFAIK there is no way to make an asynchronous call to a VBScript function, since you can't define events in ASP, and that's something you need to be able to know you results have return properly,
That's what I figured. Couldn't hurt to ask though.

but, since you managed to work async with a stored procedure through ADO, maybe there's a way to call the COM object from an stored proc which is
perfectly possible if you are using MS SQL server as your DB.

Yech. No MS Sql Server here. I'm using Firebird. I could probably put
together a UDF to make the call, but that doesn't seem to be a proper
seperation of the data/application layers. More likely, I'll implement

the call to our middle tier in the com object, and let the middle tier create
the report.

Btw, I'm curious how that async stored-procedure magic works in ASP though,

would you mind sharing a snippet of code? :)

Sure.

We've got an include file called DbLibrary.asp, which contains all of the
logic for connecting/opening datasets/disconnecting. In this library is

the function for executing an async query:

function ExecuteSqlAsync(ASQL)
{
var vCount = 0;
vDBConnection.Execute(ASQL,vCount,0x10);
}

The 0x10 flag is equivalent to the constant adAsyncExecute.

The long running process is kicked off when a user makes a change to a
pricing model. We first generate a unique id for tracking the progress of
this event, then kick off the stored procedure via the above call. We then redirect to a generic please wait page. This page shows a message to the
user, as well as an animated progress bar. It also contains an invisible
IFRAME, whose source is a page called WaitBackground.asp.

WaitBackground contains a refresh header set to 5 seconds. Each time the
page refreshes, it checks a table to see the status of the job (keyed by the ID mentioned above, and updated by the stored procedure). If the job status is complete, we use client side js to do a 'parent.document.location = ',
and show whatever page the user should be taken to.

All in all, it works very well, for both the short updates (the user sees
the progress screen for just a few seconds), and for longer updates (they
still have to wait, but are entertained by the animated progress bar moving back and forth <g>).

Bob M..

<!--#include virtual='/Shared/Server/DbLibrary.asp' -->
<%

function SaveStopRateModel(AProcessStatusId)
{
vSql =
"execute procedure inv_save_stop_rate_revision(" +
Request('revid') + "," +
AProcessStatusId + ");"
ExecuteSqlAsync(vSql);
}

ConnectDb();
var vNewId = GetNewId2('PROCESS_STATUS_GEN');
SaveStopRateModel(vNewId);
Session("ProcessStatusUrl" + vNewId) = 'StopRateEdit.asp';
Session("ProcessStatusMsg" + vNewId) = escape(
'Your changes to the stop rate model are being saved.<BR><BR>' +
'Please wait while salescheck stop rates are updated based on your
selected "Effective Date".<BR><BR>' +
'This process could take up to two minutes. You will be returned to the
stop rate editor when complete.');
Response.redirect('PleaseWait.asp?processid=' + vNewId);
%>

[Bob Murdoch]

"J. Baute" <WU**********@spammotel.com> wrote in message
news:40***********************@news.skynet.be...

Why not call a .vbs script from ASP by using the WScript.Shell Run() method with the param bWaitOnReturn parameter set to False, which should just call the VBS script and get on with the rest of the ASP code.

Now that, my friend, is a good idea indeed. I just might have a go at that.

Thanks for the idea.

Bob M..