Taco The process wouldnt work if you had more than 1 user hitting the same page.
You process only uses a single table for all records If i hit the page then you hot the page, I would no longer have my results when i hit the next button, I would have yours. As a result of this, to make your process more flexible, you would I think need to create tables on the fly to hold a sprecific users records. 100 concurrent users would then mean 100 extra tables in your database. You would then also need to have dbOwner rights to the database to do so. Also, would this mean that you would have to create a tmp table for each type of paging display? Or am i not reading your SP correctly? Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Taco Fleur Sent: Sunday, 1 February 2004 2:34 PM To: CFAussie Mailing List Subject: [cfaussie] Re: Efficient Paging - follow up on an old post Hi Peter, Not sure whether I understand your post or whether you understand mine ;-)) But the method I am proposing does not use cached queries at all. Cached queries is nice for little apps, but as you say yourself its limited to a certain amount of cached queries, thus not the ideal method for a heavily used search interface. Even so, a cached query transfers ALL data in the resultset to the app, the method I am proposing/using does not transfer any more data than required upon each request. Where the [EMAIL PROTECTED] is everyone? are we the only ones working in the weekend? Taco Fleur Blog http://www.tacofleur.com/index/blog/ Methodology http://www.tacofleur.com/index/methodology/ Tell me and I will forget Show me and I will remember Teach me and I will learn > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Peter Tilbrook > Sent: Sunday, 1 February 2004 1:20 PM > To: CFAussie Mailing List > Subject: [cfaussie] Re: Efficient Paging - follow up on an old post > > > Caching the query for "paging", ie next 10 records, previous > 10 records, firs page, last page, is a great idea. > > But take this into account first: > > How "dynamic" will the list be - if not altogether dynamic - great. > > Otherwise - if the database data is changed, force a database > "refresh" to the same scope as your cached query to ensure > the end user is seeing the up-to-date information. > > Apart from that this method can really help your application > performance, as long as you respect the amount of memory you > server has and the limit of (100 cached queries I believe - > limited by the servers memory - 1 cached query could kill it) > that CF has for this. > > --- > 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 --- 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 --- 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
