With all the respect you deserve from me, you are oversimplifying the issue.

ROWNUM sure isn't perfect, but no more is needed for a Web application. Web
users seem understand/don't care if there are small glitches in the order
of data from one request to the other.
- They do not expect to be browsing a snapshot from the moment they started
the search that originated the list of pages;
- They understand that each page is a request and that the underlying data
can change in between;
- They sometimes jump several/many pages forward or backwards (which makes
the paging a harder problem);
- They often quit/find what they want after a couple of clicks, often to
start a new search (which makes caching all data space consuming + a
waste of processing power);
- They still want the site to be fast.

Being an Internet user, maybe you can recognize the above scenario.

For the above issues, I find what I propose above the best solution. And I
am not the only one.

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Jason Wharton [mailto:jwharton@...]
> Sent: Friday, June 01, 2001 4:53 AM
>
>
> All this talk about the server delivering portions of a dataset based on
> ROWNUM ranges is nauseating.
>
> AFAIK, InterBase/Firebird does not have the concept of a row number on the
> server. This belongs on a client that is actually fetching data
> and counting
> rows as it goes and keeping them in a cache of its own. The server should
> not be required to keep hordes of caches around just to spit out small
> slices of datasets efficiently. Nor should it be made to
> re-execute queries
> over and over again just to increment through data.
>
> What should be happening is using bookmarks derived from
> meaningful data in
> your table that allows the server to quickly pull records from the next
> segment and then it just brings back rows until you don't want any more.
> When you want more records you somehow say, this is the new starting point
> and I want some more records starting from there.
> Interbase/Firebird handles
> that very well. IBO even automates with its various searching facilities.
>
> By doing it this way you are able to walk a batch of records more
> accurately. Row Nums are potentially inaccurate. They are always
> relative at
> best.
>
> e.g. Someone is browsing a web site and they see recs 1-50, while they are
> doing that one of the records they are looking at becomes deleted and then
> when they page to rows 51-100 the record that used to be 51 is now 50 and
> guess what, they never see that record. If instead their request for more
> records was based on records after the value for record 50 they would pick
> up that record and not miss it. using a snapshot transaction is definitely
> not a solution to this problem either.
>
> ROWNUM is simply for lazy programmers who don't really care if their
> applications work 100%. I vote for them to be banished from the
> engine even
> if any such semantics are already there. This part of the
> complexity should
> be solved on a middle tier or client. A server's job is to do
> transactions,
> optimize whatever queries I throw at it and keep data integrity.
>
> I suppose if you really want them it is a snap to write select stored
> procedures that provide a row num facility...
>
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
>
> Community email addresses:
> Post message: IBDI@yahoogroups.com
> Subscribe: IBDI-subscribe@yahoogroups.com
> Unsubscribe: IBDI-unsubscribe@yahoogroups.com
> List owner: IBDI-owner@yahoogroups.com
>
> Shortcut URL to this page:
> http://www.yahoogroups.com/community/IBDI
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>