Roy,

<< Yorkshireman living in Scotland please! >>

Oops, my apologies.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dave,

<< What, no ranges in EDB? >>

Ranges also would work, but they would be slightly slower than a single-row
findkey or locate.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy Lambert wrote:

>
> Yorkshireman living in Scotland please!
>

Well if you have the misfortune not to be Scottish, I would have to
concede that Yorkshire is a damn good second best.

I have some very good White Rose friends.

Malcolm
--

Tim Young [Elevate Software] wrote:
>
> It really depends upon your needs, ... TEDBQuery
> (sensitive result set), and finally TEDBQuery (insensitive result set).
>

I was under the impression that an insensitive result set would be
faster in general.  Is there a rule of thumb I can use to determine
whether it's faster to use a sensitive result set or an insensitive
result set when performing a query?  Indexed query vs non-indexed query,
single table vs join, etc?

--
Gordon Turner
Mycroft Computing
http://www.mycroftcomputing.com

Gordon,

<< I was under the impression that an insensitive result set would be faster
in general.  Is there a rule of thumb I can use to determine whether it's
faster to use a sensitive result set or an insensitive result set when
performing a query?  Indexed query vs non-indexed query, single table vs
join, etc? >>

Large, single-table queries with no ORDER BY are always fastest with a
sensitive result set.  Single-table queries that only select a very few rows
out of very many and have an ORDER BY are usually faster with an insensitive
result set.   With anything else, the sensitive/insensitive aspect doesn't
matter or doesn't apply.  For example, with joins the result set is always
insensitive anyways.

http://www.elevatesoft.com/edb1sql_result_set_cursor_sensitivity.htm

--
Tim Young
Elevate Software
www.elevatesoft.com