Subject | Re: [IB-Architect] Bi-Directional cursor support WAS: Re: triggers + plans |
---|---|
Author | Jim Starkey |
Post date | 2002-05-24T16:47:45Z |
At 12:31 PM 5/24/02 -0400, Leyne, Sean wrote:
used as part of scrollable cursors. Scrollable cursors, in my
always humble opinion, a really stupid way to implement window
scrolling, and should be client side, application specific
functionality.
Index walking in Interbase/Firebird is always problematic due
to an inherent inprecision of the indexes (all numbers and dates
are converted to double precision floating with inevitable
roundoff problems). The index scan code must revalidate a
candidate record to compensate for record generation issues,
this isn't a problem. But it is a nasty problem for index
walking, expecting to get a strict ordering.
But before I reached a conclusion, I would wait for a rebuttal
from folks that have applications dependent on them.
Jim Starkey
>Jim,Reasonable men can differ. Bidirectional cursors are usually
>
>Would the same be said (kill it!) for the logic which support
>bi-directional cursors?
>
>I understood that they where introduced as part of the dBase
>IV-emulation, but then again I could have that wrong.
>
>If it wasn't for dBaseI IV, what purpose/benefit does bi-directional
>cursors have?
used as part of scrollable cursors. Scrollable cursors, in my
always humble opinion, a really stupid way to implement window
scrolling, and should be client side, application specific
functionality.
Index walking in Interbase/Firebird is always problematic due
to an inherent inprecision of the indexes (all numbers and dates
are converted to double precision floating with inevitable
roundoff problems). The index scan code must revalidate a
candidate record to compensate for record generation issues,
this isn't a problem. But it is a nasty problem for index
walking, expecting to get a strict ordering.
But before I reached a conclusion, I would wait for a rebuttal
from folks that have applications dependent on them.
Jim Starkey