Another thing, when using stored procedures there is no query caching function. And SPs is all use now these days.
What I am doing at the moment (and I am still not happy with it) is passing the currentPage and maxRow values to the stored procedure, once in the stored procedure I do MS SQL DECLARE @maxRow = @currentPage * @maxRow SET ROWCOUNT @maxRow Which means if I am on the first page it only gets 10 records, second page 20 records 9th page 90 records and so on, but still on each request I am retrieving records that I do not need (i.e. use up system resources and network traffic). OK I have narrowed the returned resultset down a bit, but I want it perfect... Did you understand why I wanted to extend the caching functionality? --- A session like Caching functionality, i.e. Cache session for 5 minutes, if the Cached version is accessed again within 5 minutes, the cache time extends itself another 5 minutes and so on. If not accessed again within 5 minutes then expire... --- It's nice that you can cache a query, but caching to many queries will eventually affect performance, and how long should you cache them for, if you cache them to long it is bad for the system, if you cache them to short the caching might not work. It would be good if the caching worked like a session, you set it low, but it extends itself upon each request. OK, I know I am being picky, and this is only a worry when you start to work with high traffic sites - but I have and am working on high traffic sites. <quote> I think this may end up being a case of trying to double-guess what the user may do next </quote> Correct, but not if the caching worked like a session (I reckon anyway). It's a shame you can't set the time-out for a specific session variable, otherwise it could be done by storing the resultset in a session variable, that you set low to expire (2 minutes or so). Whatever the case, caching queries does not look like the optimal process to achieve paging. It would still be better if you could say to (MS SQL) give me row 31 to 40, row 41 to 50 blah blah blah I am probably rambling on........ "It's a sensitive issue that has bothered me for a long time"... Taco Fleur Tell me and I will forget Show me and I will remember Teach me and I will learn --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
