Question : Page Time out with heavy store procedure calls

I have some heavy store procedures which are taking time in Hrs and hence I am getting time out on the page. To avoid script time out I tried setting the ScriptTimeout in config as well as in Page (I am testing it in debug mode). Is there any possibility that we can avoid page time out for long running tasks. Or is there any solution to make Asynch call and refresh the same page with the data after callback?

Answer : Page Time out with heavy store procedure calls

No, the TCP timeout is set at the O/S level someplace (I know where it is on Linux put don't off the top of my head in Windows).

There are two or three approaches you can take.

1)  Install and configure the Sybase Job Scheduler.  This facility is included free with Sybase and gives you the ability to schedule jobs on a one-time or recurring basis.  You can configure and schedule jobs using Sybase Central or through a fairly extensive stored procedure interface.  The way it would work is to have the user web page enter whatever parameters are required and call a stored procedure that creates and schedules the "job" (your stored procedure run) in the job scheduler.

You then have a couple of choices on how to let the user come back at a later time and pickup the results.  Assuming your stored procedure returns a result set, you will need to have a table to stuff it in with a Job ID column on the front of whatever the primary key might be.  You can then pick up the results with a simple query or SP against the results table by Job ID.  You may have to create a little tracking table that collects the Job IDs by User ID/Name/Login (whatever) so the user doesn't have to remember his Job ID.  You can also hook that up so that it gets the status from the Job Scheduler so the users can see what is done.

2)  You can use an undocumented feature of Sybase ASE to run a process in the background.  The one annoying thing about the background command is that it breaks the connection to the client; as if it were a forced logout.  This is not impossible to get around with some dynamic SQL trickery.  You still have the same issues with tracking outstanding and completed "jobs" but you are going to have to deal with that in any run-and-return-later scenario.

3)  You can create a deamon process that runs and poles a queue table periodically.  Users request a run of a stored procedure; a process that puts an entry in the queue table.  The deamon lights up every 15 second or so, looks for the next entry in the queue table, and if it finds one, goes off and runs the target SP with the appropriate parameters.  When it returns, it marks the queue record as FINISHED and looks for the next one.  The potential advantage of this technique over the Job Scheduler is that you can single thread the execution so that you don't get 5 or 10 of these things crushing the system at the same time.

This kind of thing is tricky to get setup and working well the first time, however; after you get the infrastructure worked out, you can apply it all over the place.

Regards,
Bill