Board index » delphi » TTable.Locate not working

TTable.Locate not working

Hi,

I'm tearing my hair out over this.

I have two TTables, one in a Data Module (dmSecy) and one in the current
form.  Both TTables have the same name (TabAcct).  (I know using the same
name in two places can be confusing, but it should work).

I want to know if there is a record in the local table (the one in the
current form) that matches the selected record in the table in the Data
Module.

Locate doesn't work!

Here's the code:

   with TabSecy do  //TabSecy refers to the TTable in the current form.
   begin

     // This is a brute force search for a matching record
     First;
     while not Eof do
     begin
       if (FieldByName('Symbol').asString
         = dmSecy.TabSecy.FieldByName('Symbol').asString) then
         Break;
       Next;
     end;
     if (FieldByName('Symbol').asString
         = dmSecy.TabSecy.FieldByName('Symbol').asString)

  // The locate, which is shown commented out, ALWAYS causes the program to
  // go to the Append statement.  Never the Edit statement.
     {if Locate(
          'Symbol',
          dmSecy.TabSecy.FieldByName('Symbol').asString,
          [])}

            then
       Edit
     else
     begin
       Append;
       // more statements...

When I use the brute force approach, it works.  When I comment out the brute
force approach and use the Locate method, it NEVER works.  IOW, Locate
always results in control going to the Append statement; never the Edit
statement.

The Locate syntax seems O.K., unless I'm missing something.

Am I doing something wrong?  Are there some conditions under which Locate
won't work?  Or is there a bug in Delphi that I'm unaware of?

This is D3 with the latest patches (3.02 I think).  I have downloaded and am
using BDE 5.0

Thanks for your help.

Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

 

Re:TTable.Locate not working


Just a wild guess but try adding the table name to the Locate call:

Table1.Locate...

--
Bill Todd
(Sorry but TeamB cannot answer questions received via email)
(Remove nospam from my email address to contact me for any other reason)

Re:TTable.Locate not working


Thanks for the suggestion.  I tried adding the table name (and then even the
form name) to the locate.

It makes no difference.

This is driving me nuts!<s>

Is it possible that I've got a syntax error that I'm just overlooking.

Otherwise,  it would seem to indicate a bug in Delphi.  But that would
really surprise me.  A bug like this would most likely have been found long
ago.   Unless, perhaps, this has something to do with DBE 5.

Thanks,   Ed

P.S.  Just for completeness, I've include the same source code as before,
but this time with the brute force approach commented out and the Locate
qualified to the form and table:

   with TabSecy do
   begin

     { //Brute force method shown commented out
  First;
     while not eof do
     begin
       if (FieldByName('Symbol').asString
         = dmSecy.TabSecy.FieldByName('Symbol').asString) then
         Break;
       Next;
     end;
     if (FieldByName('Symbol').asString
         = dmSecy.TabSecy.FieldByName('Symbol').asString)}

     // Locate method qualified to form and table.
     if FrmTrnSecy.TabSecy.Locate(
          'Symbol',
          dmSecy.TabSecy.FieldByName('Symbol').asString,
          [])

           then
       Edit
     else
     begin
       Append;

Thanks again,   Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Quote
Bill Todd (TeamB) wrote in message <6r02na$9...@forums.borland.com>...
>Just a wild guess but try adding the table name to the Locate call:

>Table1.Locate...

>--
>Bill Todd
>(Sorry but TeamB cannot answer questions received via email)
>(Remove nospam from my email address to contact me for any other reason)

Re:TTable.Locate not working


Hi,

A bit more information.

I tried changing the name of the table in the current form.  So now, the two
tables have different names.  Yet the problem persists.

Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Re:TTable.Locate not working


You might check to insure that trailing spaces are being handled the same way in
the key of each table.  If the field to which you are referring is part of a
compound key in the index, then I think you also have to specify loPartialKey to
keep Locate from using nil values for the other fields in the key.

Quote
Ed Hochman wrote:
> Hi,

> I'm tearing my hair out over this.

> I have two TTables, one in a Data Module (dmSecy) and one in the current
> form.  Both TTables have the same name (TabAcct).  (I know using the same
> name in two places can be confusing, but it should work).

> I want to know if there is a record in the local table (the one in the
> current form) that matches the selected record in the table in the Data
> Module.

> Locate doesn't work!

> Here's the code:

>    with TabSecy do  //TabSecy refers to the TTable in the current form.
>    begin

>      // This is a brute force search for a matching record
>      First;
>      while not Eof do
>      begin
>        if (FieldByName('Symbol').asString
>          = dmSecy.TabSecy.FieldByName('Symbol').asString) then
>          Break;
>        Next;
>      end;
>      if (FieldByName('Symbol').asString
>          = dmSecy.TabSecy.FieldByName('Symbol').asString)

>   // The locate, which is shown commented out, ALWAYS causes the program to
>   // go to the Append statement.  Never the Edit statement.
>      {if Locate(
>           'Symbol',
>           dmSecy.TabSecy.FieldByName('Symbol').asString,
>           [])}

>             then
>        Edit
>      else
>      begin
>        Append;
>        // more statements...

> When I use the brute force approach, it works.  When I comment out the brute
> force approach and use the Locate method, it NEVER works.  IOW, Locate
> always results in control going to the Append statement; never the Edit
> statement.

> The Locate syntax seems O.K., unless I'm missing something.

> Am I doing something wrong?  Are there some conditions under which Locate
> won't work?  Or is there a bug in Delphi that I'm unaware of?

> This is D3 with the latest patches (3.02 I think).  I have downloaded and am
> using BDE 5.0

> Thanks for your help.

> Ed

> --
> Ed Hochman
> MBH Systems
> e...@nospam.mbhsys.com
> Please remove the nospam to reach me via e-mail.

--
Wayne Herbert
Manager, Computer Products
Key Maps, Inc.
1411 West Alabama
Houston, TX  77006

Vox:  713.522.7949
Fax:  713.521.3202
Email:  wherb...@keymaps.com

Vyizder mororsiz assesden derizorsiz?

Re:TTable.Locate not working


Thanks for the ideas.

I tried loPartialKey to no avail (same problem).

The tables are Paradox tables.  In fact, there is only one physical table.
Both TTables point to the same Paradox table.

The Primary key is <field1>, <field2>, Symbol, <field4>  where Symbol is the
field I'm "Locating" for.

The Secondary key is based on Symbol alone.

I would expect the BDE to use the secondary index since gives an exact match
to the Locate criteria.  But I don't think there is any way to know for
sure.

Both TTables are children in a parent/child relationship.  At the time I do
the Locate, the two TTables have different parents, so the Locate is looking
at a subset of the full table and is NOT looking at the same records as the
other table (the one that is providing the value of Symbol I'm searching
for).   (Boy, I hope I said that clearly enough.  Even I'm confused now<g>.)

Anyway, the contents of the Symbol field is typically 1 to 6 characters in a
15 character field.  Since the underlying dataset is the same, I know that
trailing spaces are handled identically.

So I continue to go bald over this<s>.  I just don't have a clue as to what
could be wrong unless there is truly a bug here.

Thanks for your help.

Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Quote
Wayne Herbert wrote in message <35D4493C.B1530...@keymaps.com>...
>You might check to insure that trailing spaces are being handled the same
way in
>the key of each table.  If the field to which you are referring is part of
a
>compound key in the index, then I think you also have to specify
loPartialKey to
>keep Locate from using nil values for the other fields in the key.

Re:TTable.Locate not working


Try rebuilding the table using the table repair utility and see if that
makes a difference.  The only other thing I can think of is a corrupt table
or index.

--
Bill Todd
(Sorry but TeamB cannot answer questions received via email)
(Remove nospam from my email address to contact me for any other reason)

Re:TTable.Locate not working


Hmmm.... OK, a couple of more thoughts.

What happens if you replace the Locate with a FindKey... if you do this, then
you must indicate the index name in your ttable properties of the secondary
index that you are going to use.  I'd guess that if FindKey works and Locate
does not you might have found a 'feature', unless....

A second random thought... Locate does not say that you must specify an index
name matching the field you are searching on, but have you tried specifying this
in your ttable properties?  AS I think about it, I've always used Locate on a
primary key (for paradox, a blank index name).

Good luck... have a great weekend!   :>)

Quote
Ed Hochman wrote:
> Thanks for the ideas.

> I tried loPartialKey to no avail (same problem).

> The tables are Paradox tables.  In fact, there is only one physical table.
> Both TTables point to the same Paradox table.

> The Primary key is <field1>, <field2>, Symbol, <field4>  where Symbol is the
> field I'm "Locating" for.

> The Secondary key is based on Symbol alone.

> I would expect the BDE to use the secondary index since gives an exact match
> to the Locate criteria.  But I don't think there is any way to know for
> sure.

> Both TTables are children in a parent/child relationship.  At the time I do
> the Locate, the two TTables have different parents, so the Locate is looking
> at a subset of the full table and is NOT looking at the same records as the
> other table (the one that is providing the value of Symbol I'm searching
> for).   (Boy, I hope I said that clearly enough.  Even I'm confused now<g>.)

> Anyway, the contents of the Symbol field is typically 1 to 6 characters in a
> 15 character field.  Since the underlying dataset is the same, I know that
> trailing spaces are handled identically.

> So I continue to go bald over this<s>.  I just don't have a clue as to what
> could be wrong unless there is truly a bug here.

> Thanks for your help.

> Ed

> --
> Ed Hochman
> MBH Systems
> e...@nospam.mbhsys.com
> Please remove the nospam to reach me via e-mail.

> Wayne Herbert wrote in message <35D4493C.B1530...@keymaps.com>...
> >You might check to insure that trailing spaces are being handled the same
> way in
> >the key of each table.  If the field to which you are referring is part of
> a
> >compound key in the index, then I think you also have to specify
> loPartialKey to
> >keep Locate from using nil values for the other fields in the key.

--
Wayne Herbert
Manager, Computer Products
Key Maps, Inc.
1411 West Alabama
Houston, TX  77006

Vox:  713.522.7949
Fax:  713.521.3202
Email:  wherb...@keymaps.com

Vyizder mororsiz assesden derizorsiz?

Re:TTable.Locate not working


Ed:

        I do alot of work using Locate with Paradox tables. I have used locate
to avoid having to set file indexes. Locate has always worked very well.

        Suggestion 1: Are you accounting for blank spaces in the items you are
searching on ??? I had trouble with some search strings until I
eliminated trailing blanks ( leading blanks also ). If you have a
mismatch between the string in the file versus the string in the locate
statement, locate will not find the item. You might look at the data is
the file character by character and compare it to the data in the search
string character by character.

        Suggestion 2: Try doing some diagnosis by setting a key on that field
and using findkey. If you can get findkey to work then locate should
work.

        Suggestion 3: Have you set any events up in the dataset which could be
interfering in the search process ???

        Suggestion 3: repair your table via a Paradox repair utility.

        I Hope this may have been some help to you.

        Sincerely,

        Neil Huhta

Re:TTable.Locate not working


I'll try this and report back.

Oh, I just realized that I don't (think) I have the utility for BDE 5.

I don't know if it's been released yet.

I did open the table with the index set to the SymbolIndex (index based on
that one field) and used a dbGrid to scroll through the table.  It did
appear to be OK.

Thanks,  Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Quote
Bill Todd (TeamB) wrote in message <6r26s0$bt...@forums.borland.com>...
>Try rebuilding the table using the table repair utility and see if that
>makes a difference.  The only other thing I can think of is a corrupt table
>or index.

>--
>Bill Todd
>(Sorry but TeamB cannot answer questions received via email)
>(Remove nospam from my email address to contact me for any other reason)

Re:TTable.Locate not working


Thanks for all the suggestions.

I use Locate quite a bit too and it's always worked for me too.  That's why
I'm so frustrated here.

1.  I'm pretty sure that angle is already covered.  The Symbol field is
always set programmatically from a pick list of allowable values.  So if the
value of the symbol is 'ABC', for example, It will ALWAYS be exactly 'ABC'.

Also,  when I use the "brute force" approach, I am still doing a compare on
the Symbol field and the comparison works.  So unless there is a fundamental
difference between the way Locate examines the field (of which I'm not
aware), this should not be a problem.

2.  I'll give it a try.

3.  No.  Part of the reason that I use two TTables for the same underlying
data file is that the one in the Data Module DOES have a lot of events.  The
one on the form (the one involved in the Locate) is completely {*word*269} in
that respect.

3(a).  Yes, I'm going to try this if I can find the TUtility for BDE 5.

Thanks,   Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Quote
nhuhta wrote in message <35D4B5D8.7...@digital.net>...
>Ed:

> I do alot of work using Locate with Paradox tables. I have used locate
>to avoid having to set file indexes. Locate has always worked very well.

> Suggestion 1: Are you accounting for blank spaces in the items you are
>searching on ??? I had trouble with some search strings until I
>eliminated trailing blanks ( leading blanks also ). If you have a
>mismatch between the string in the file versus the string in the locate
>statement, locate will not find the item. You might look at the data is
>the file character by character and compare it to the data in the search
>string character by character.

> Suggestion 2: Try doing some diagnosis by setting a key on that field
>and using findkey. If you can get findkey to work then locate should
>work.

> Suggestion 3: Have you set any events up in the dataset which could be
>interfering in the search process ???

> Suggestion 3: repair your table via a Paradox repair utility.

> I Hope this may have been some help to you.

> Sincerely,

> Neil Huhta

Re:TTable.Locate not working


Hi,

Thanks for the ideas.

Quote
>What happens if you replace the Locate with a FindKey... if you do this,
then
>you must indicate the index name in your ttable properties of the secondary
>index that you are going to use.  I'd guess that if FindKey works and
Locate
>does not you might have found a 'feature', unless....

I'm going to try this.

Quote
>A second random thought... Locate does not say that you must specify an
index
>name matching the field you are searching on, but have you tried specifying
this
>in your ttable properties?  AS I think about it, I've always used Locate on
a
>primary key (for paradox, a blank index name).

H'mm.  I'll give this a try.

Thanks,  Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Re:TTable.Locate not working


Well I think I've found the problem.

Locate, as I formulated it, won't work if the table has
MasterSource/MasterFields properties.

I've found two ways to get around this.

1.  Remove the MasterSource/MasterFields properties and use a Filter
instead.

2.  Restate the Locate so that all fields in the primary index, up to and
including the Symbol field, are included.  Here's what I used:

     if Locate ('Institution;ACID;Symbol',
       VarArrayOf([
          TabAcct.FieldByName('Institution').asString,
          TabAcct.FieldByName('ACID').asString,
          dmSecy.TabSecy.FieldByName('Symbol').asString
          ]),
       [])

It seems that the fact that Symbol is in the primary key, but not the first
field in the key, means that you can't Locate on just that one field.

I have another Locate on another table that works on a field that is not a
part of the primary key.  This works.  So I assume that the problem only
occurs if the field is in the key but not the first field.

I don't know if this is a limitation in all versions of Delphi and the BDE;
but it certainly is the case with D3.02 and BDE 5.0.

This is not the behavior of Locate that I expected after reading the Help
file.  I doubt it is what was intended by the development team.

Should this be reported as a bug?

I also tried, as was suggested, setting the IndexName and/or IndexFieldName
properties to the secondary index (which is based only on the Symbol field).
This cannot be done when there is a MasterSource.  Trying it results in
"Field index out of range".

This is understandable since it would create an inconsistency between the
IndexField and MasterSource.

Thanks to all who helped on this.  All of your suggestions helped me to
unravel the problem.

Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Re:TTable.Locate not working


Quote
Ed Hochman wrote:

> Well I think I've found the problem.

> Locate, as I formulated it, won't work if the table has
> MasterSource/MasterFields properties.

> I've found two ways to get around this.

> 1.  Remove the MasterSource/MasterFields properties and use a Filter
> instead.

Having a MasterSource/Masterfield set means that a range is applied
to the table, depending, on the field values in the master record.
Locate only works on what is available in the result set - which is the
result of any applied ranges and filters.

So, if the record you try to locate is outside of this
result set (i.e. the range set up by the master record),
then Locate will not find it.

Are you sure the currently active ranges always included what you
were looking for?

Quote
> 2.  Restate the Locate so that all fields in the primary index, up to and
> including the Symbol field, are included.  Here's what I used:

>      if Locate ('Institution;ACID;Symbol',
>        VarArrayOf([
>           TabAcct.FieldByName('Institution').asString,
>           TabAcct.FieldByName('ACID').asString,
>           dmSecy.TabSecy.FieldByName('Symbol').asString
>           ]),
>        [])

> It seems that the fact that Symbol is in the primary key, but not the first
> field in the key, means that you can't Locate on just that one field.

I have just duplicated your basic setup with the orders.db and items.db tables from
the DBDEMOS sample database. the items.db table (as detail table) has a primary
key on the fields OrderNo and ItemNo. The link is based on the OrderNo field
in both tables. I did the Locate on the second field of the detail table's
linking index,, i.e. ItemNo, and as long as the detail range included the value I was
looking for, the Locate was successful - with MasterSource and MasterFields set.
I am, however, using Delphi 4 with Upddate 1 applied.

Quote

> I have another Locate on another table that works on a field that is not a
> part of the primary key.  This works.  So I assume that the problem only
> occurs if the field is in the key but not the first field.

> I don't know if this is a limitation in all versions of Delphi and the BDE;
> but it certainly is the case with D3.02 and BDE 5.0.

> This is not the behavior of Locate that I expected after reading the Help
> file.  I doubt it is what was intended by the development team.

Well, the Delphi help files are well know for leaving out some details. :-(

Quote
> Should this be reported as a bug?

I am not convinced yet - since it works here.

Karl

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Karl Waclawek
   KD Soft Inc.
 * Phone:  (905) 579-3443
 * E-Mail: wacla...@idirect.com

Re:TTable.Locate not working


Hi Karl,

Thanks for your analysis!

Yes, I'm sure that the record I'm looking for is within the range imposed by
the MasterSource relationship.

It's quite possible that the problem is dependent on the version of Delphi
and the BDE.

Also, I only have this one case to report so I can't say that there are no
other factors besides the ones I've reported.

I'll re-create your test and see what happens.

Ed

--
Ed Hochman
MBH Systems
e...@nospam.mbhsys.com
Please remove the nospam to reach me via e-mail.

Quote
Karl Waclawek wrote in message <35D51BFA.CE923...@idirect.com>...
>Having a MasterSource/Masterfield set means that a range is applied
>to the table, depending, on the field values in the master record.
>Locate only works on what is available in the result set - which is the
>result of any applied ranges and filters.

>So, if the record you try to locate is outside of this
>result set (i.e. the range set up by the master record),
>then Locate will not find it.

>Are you sure the currently active ranges always included what you
>were looking for?

>I have just duplicated your basic setup with the orders.db and items.db
tables from
>the DBDEMOS sample database. the items.db table (as detail table) has a
primary
>key on the fields OrderNo and ItemNo. The link is based on the OrderNo
field
>in both tables. I did the Locate on the second field of the detail table's
>linking index,, i.e. ItemNo, and as long as the detail range included the
value I was
>looking for, the Locate was successful - with MasterSource and MasterFields
set.
>I am, however, using Delphi 4 with Upddate 1 applied.

>Well, the Delphi help files are well know for leaving out some details. :-(

>> Should this be reported as a bug?

>I am not convinced yet - since it works here.

>Karl

>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   Karl Waclawek
>   KD Soft Inc.
> * Phone:  (905) 579-3443
> * E-Mail: wacla...@idirect.com

Go to page: [1] [2]

Other Threads