Board index » delphi » Using the locate method with a TQuery

Using the locate method with a TQuery

Hi All,

I am trying to replace a sequential search on the result set of a TQuery
with a call to the locate method.

I have the call to locate working but it takes just as long as the
sequential search which leads me to believe that it is not using the index
that is available.  I am using Delphi c/s 4.0 BDE 5.1 and Oracle 7.3.

The query goes like this:

"select Item_ID, <about 8 other fields> from Items where Loc_ID = <XXX> and
Item_Level = <YYY>"

Item_ID, Loc_ID, and Item_Level are all numeric fields and Item_ID is the
primary key for the table.

Locate usage:

qResults.Locate('Item_ID', iItemID, [ ]);

Shouldn't the locate use the primary key since that is the field I am
searching on and that field is available is the query results.

As I said the call to locate takes as long as the sequential search,
shouldn't it be faster?

Any ideas?

Thanks,

Joe

 

Re:Using the locate method with a TQuery


Is it possible that Oracle just doesn't use the index optimally? You can
achieve this by the following command (in Oracle SQLPlus):

execute dbms_utility.analyze_schema('<owner>', 'compute');

This updates all the indices owned by <owner>.

In article <7c5qb6$6j...@oak.prod.itd.earthlink.net>,
  "Joe McPherson" <joemcpher...@prescientsystems.com> wrote:

Quote
> Hi All,

> I am trying to replace a sequential search on the result set of a TQuery
> with a call to the locate method.

> I have the call to locate working but it takes just as long as the
> sequential search which leads me to believe that it is not using the index
> that is available.  I am using Delphi c/s 4.0 BDE 5.1 and Oracle 7.3.

> The query goes like this:

> "select Item_ID, <about 8 other fields> from Items where Loc_ID = <XXX> and
> Item_Level = <YYY>"

> Item_ID, Loc_ID, and Item_Level are all numeric fields and Item_ID is the
> primary key for the table.

> Locate usage:

> qResults.Locate('Item_ID', iItemID, [ ]);

> Shouldn't the locate use the primary key since that is the field I am
> searching on and that field is available is the query results.

> As I said the call to locate takes as long as the sequential search,
> shouldn't it be faster?

> Any ideas?

> Thanks,

> Joe

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re:Using the locate method with a TQuery


From what I have find out from the guys here, it looks like once the BDE
gets a hold of the data it can no longer use the oracle indexes.

Joe

Quote
kn...@furore.nl wrote in message <7c7u3k$el...@nnrp1.dejanews.com>...
>Is it possible that Oracle just doesn't use the index optimally? You can
>achieve this by the following command (in Oracle SQLPlus):

>execute dbms_utility.analyze_schema('<owner>', 'compute');

>This updates all the indices owned by <owner>.

>In article <7c5qb6$6j...@oak.prod.itd.earthlink.net>,
>  "Joe McPherson" <joemcpher...@prescientsystems.com> wrote:
>> Hi All,

>> I am trying to replace a sequential search on the result set of a TQuery
>> with a call to the locate method.

>> I have the call to locate working but it takes just as long as the
>> sequential search which leads me to believe that it is not using the
index
>> that is available.  I am using Delphi c/s 4.0 BDE 5.1 and Oracle 7.3.

>> The query goes like this:

>> "select Item_ID, <about 8 other fields> from Items where Loc_ID = <XXX>
and
>> Item_Level = <YYY>"

>> Item_ID, Loc_ID, and Item_Level are all numeric fields and Item_ID is the
>> primary key for the table.

>> Locate usage:

>> qResults.Locate('Item_ID', iItemID, [ ]);

>> Shouldn't the locate use the primary key since that is the field I am
>> searching on and that field is available is the query results.

>> As I said the call to locate takes as long as the sequential search,
>> shouldn't it be faster?

>> Any ideas?

>> Thanks,

>> Joe

>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

Other Threads