On Sat, 2002-08-17 at 10:40, Jeff Zucker wrote: > A M Thomas wrote: > > > > It makes a lot of sense from a user interface point of view to show the > > web user the _total_ number of records that match the search criteria, > > and possibly, calculated from that, the number of batches (think > > Google). > > > I don't know of any way in SQL other than a second COUNT (*) query. You > may be better off doing the LIMIT part in perl rather than SQL -- do the > full query, get the rows() to find the total matching the query. If you > can spare the memory, use selectall_arrayref and perform your limit with > a splice. Otherwise, loop through a fetch with a counter and stop after > the desired limit. Either of those would avoid a second query.
An alternative if you have a well defined primary key is to first fetch all the primary keys for the query, and cache these locally. That gives you the total number of rows. Now for each page you fetch the rows where the primary key is in the range that you are looking for for that page. Unless you have potentially *huge* result sets this should work pretty well. Michael -- Michael Peppler / [EMAIL PROTECTED] / http://www.mbay.net/~mpeppler [EMAIL PROTECTED] / ZetaTools, Inc / http://www.zetatools.com ZetaTools: Call perl functions as Sybase stored procedures!
signature.asc
Description: This is a digitally signed message part
