Sam,

<< Yes, your suggestion to make it insensitive got it down to 100ms. Even if
I drop the sort and have it sensitive (live), it still takes 1100ms, or 10x
slower than a static query. So it looks like I need to use insensitive
queries when extracting a few rows from a large table. I guess there is some
sort of contention between sorting and filtering on the same column. >>

Yes, it has to do with re-positioning the cursor on the first row according
to the sort.  The internal set representation for filters/queries are
bitmaps in physical row number ordering, which doesn't jive with the active
sort in some cases.  It was addressed in DBISAM, but not entirely in a
satisfactory manner, which is why I punted on it for the first incarnation
of ElevateDB.  There's a better solution that will take a little more time
to put into place.

<< That's why I think a Range would be faster. Anyways, I won't worry about
it. >>

Sure, a range is faster in specific cases.  However, it isn't particularly
versatile.  A filter can do everything that a range can do, but a range
can't do everything that a filter can do.  Given the limited amount of real
estate in the EDB Manager, I went with the most versatile functionality that
could do the most with the least, which is why there are locates and
filters, but not findkeys and ranges.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

Ok. Got it.

Eduardo