First of, as you said and as I stated in earlier post, yes for different apps you might need different paging, i.e. for a small app with hardly any users caching will do, but as I said in this case its an app with at least 17000 records and multiple concurant users (maybe 20 at the max), caching would not be a good option (in my eyes) - also in this situation the db server is located from the webserver (as it should).
Caching queries means the first time you take ALL records and cache them, in my books the user hardly goes past the first two pages, thus caching XXXX records each time would be a waste. If you take this issue into consideration then the proposed solution would be better in many cases. OK, there is a bit of processing within the RDBMS, but nothing it can't handle. It would not need to be a stored procedure, but thats all I work with, unless its a data retrieval for a dropdown. "In addition, the "work" is still being done by the database server." I can't think of any way that the database server would not have to do any work? -------------- Also, when I tested this query in SQL Query Analyzer (without the @ variables and just using constants) it barfed on the quote/CAST syntax for the TOP parameter (it is expecting an integer constant apparently). -------------- Whats the error? Could be a booboo on my behalf, I had to work all weekend and did not have much time to spend on the samples, but I reckon the principle is clear to most. Taco Fleur 07 3535 5072 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: Gary Menzel [mailto:[EMAIL PROTECTED] Sent: Monday, 2 February 2004 12:48 PM To: CFAussie Mailing List Subject: [cfaussie] Re: Efficient Paging - follow up on an old post > This is what cuts down on the data transferred back and forth upon moving > form page to page... I wouldn't need to be a stored procedure. A CF query built the same way would do the same thing (the TOP happens at the SQL server - not at the CFMX end). Having said that, an execution plan show the cost of this query will be in the ORDER BY clauses - 80% in fact. TOP can actually end up being costly especially with ORDER BY clauses. In many instances the database will still have to perform a full table scan to do the ORDER BY. In addition, the "work" is still being done by the database server. As you get towards the ends of the "page sets" the inner query is returning more and more rows of which you only really want 10 (which is another query that actually executes - the queries are nested three deep). If the query being paged is used regularly then this may be more work for the database server than would make sense. While I can see this will restrict network traffic I am not convinced that you haven't just spread the workload to a different machine (depending on the frequency of execution) and that you could still be better off with a cached query. This probably highlights that each instance of paging may require it's own solutions. Also, when I tested this query in SQL Query Analyzer (without the @ variables and just using constants) it barfed on the quote/CAST syntax for the TOP parameter (it is expecting an integer constant apparently). Gary Menzel Web Development Manager IT Operations Brisbane -+- ABN AMRO Morgans Limited Level 29, 123 Eagle Street BRISBANE QLD 4000 PH: 07 333 44 828 FX: 07 3834 0828 If this communication is not intended for you and you are not an authorised recipient of this email you are prohibited by law from dealing with or relying on the email or any file attachments. This prohibition includes reading, printing, copying, re-transmitting, disseminating, storing or in any other way dealing or acting in reliance on the information. If you have received this email in error, we request you contact ABN AMRO Morgans Limited immediately by returning the email to [EMAIL PROTECTED] and destroy the original. We will refund any reasonable costs associated with notifying ABN AMRO Morgans. This email is confidential and may contain privileged client information. ABN AMRO Morgans has taken reasonable steps to ensure the accuracy and integrity of all its communications, including electronic communications, but accepts no liability for materials transmitted. Materials may also be transmitted without the knowledge of ABN AMRO Morgans. ABN AMRO Morgans Limited its directors and employees do not accept liability for the results of any actions taken or not on the basis of the information in this report. ABN AMRO Morgans Limited and its associates hold or may hold securities in the companies/trusts mentioned herein. Any recommendation is made on the basis of our research of the investment and may not suit the specific requirements of clients. Assessments of suitability to an individual?s portfolio can only be made after an examination of the particular client?s investments, financial circumstances and requirements. --- 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
