script timeout--any pitfalls?

[BrianB]

I have an online reporting application that queries a SQL 2000 database on another server and returns the data to the browser.

These recordsets can range anywhere from 1 to 8000 records, including a single varchar(8000) column.

As a result, when users foolishly grab every entry in the database, the recordset that gets returned can be enormous. The asp app uually times out unless I set the server.scripttimeout to more than half an hour.

My question is: does anyone know of any serious drawbacks to setting the script timeout to such an huge figure?


-Brian

 

[FengShui1998]

brianb,
I think you might be better off trying to restrict the number of records the user sees at one time. There is something called "paging" where the user sees the data in blocks. the "blocksize" or page size can be set up to you.

Another option would be to let the user start from the last record and page backwards if the data is almost near the back end.


fengshui1998

 

[ToddWW]

BrianB,

I agree with the previous post. Leave your script timeout as is, it'll save you headaches down the road. Try to get familiar with paging recordsets (if you already haven't), where data is returned to the browser in blocks then the user can click on a >>Next>> or <<Prev<< link to access the next or previous set of records. This forum is a good example of paging, and even provides links to page numbers so the user can jump back or forward several pages in one click. Search engines are also good examples of paging.

Let me know if you need any tips on paging.

TW