Re^3: Class::DBI Pagination with Table Joins

You're right, I wasn't clear, sorry. What I meant was: Yes, do the pagination, but No, don't pull X-thousand records to do it. Paginate by pulling only what you need. (Think Just-In-Time inventory, except w/ records.)

I can't speak Sybase SQL, and we all know that sometimes SQL seems like it's more dialect than ANSI. I've used LIMIT and OFFSET with success in my own work though, and it's *really* handy for this kind of work.

Comment on Re^3: Class::DBI Pagination with Table Joins

Replies are listed 'Best First'.
Re^4: Class::DBI Pagination with Table Joins by herveus (Prior) on Oct 13, 2005 at 18:05 UTC
Howdy! Last time I did Sybase, one could "set recordcount=x" to limit the result set to x rows, but I don't recall any analog to OFFSET. Of course, if you do pagination by repeated queries, how worried are you about getting the same result set each time (from which you draw a different subset)? If the data is fairly static, or you don't care, you can just do a fresh query each time. Otherwise, you want an iterator-like middleman to do the big query and hand you x rows at a time on demand. yours, Michael	[reply]

Replies are listed 'Best First'.

Re^4: Class::DBI Pagination with Table Joins
by herveus (Prior) on Oct 13, 2005 at 18:05 UTC

Last time I did Sybase, one could "set recordcount=x" to limit the result set to x rows, but I don't recall any analog to OFFSET. Of course, if you do pagination by repeated queries, how worried are you about getting the same result set each time (from which you draw a different subset)? If the data is fairly static, or you don't care, you can just do a fresh query each time. Otherwise, you want an iterator-like middleman to do the big query and hand you x rows at a time on demand.

yours,
Michael

[reply]