I’m using DBISAM 4.27 with Delphi 2007

When I execute this

               IF Locate('ExptID;Date;SpecID', VarArrayOf([exptID, resDate, specID]), [loCaseInsensitive]) then
                  Edit
               ELSE
                  Append;

there are times when I fail to locate the record even when it is present.  The exptID value is an integer; the resDate is a date (which appears to have an integer value), and the specID is a string.  I can be pretty sure that the exptID and specID values match; since the resDate may be stored as floating point, I can only report that the values appear to be integers and that they match.

Note that the procedure I am using to create this problem is to perform the same operations twice in a row.  The point was to test that I would catch that the record was there, and perform an Edit rather than an Append.  The Append causes a key violation, of course.  My point is that the data should be exactly the same the second time around as the first, so I would expect the Locate to succeed.  Note that the Locate works fine a dozen times before it fails.

Any thoughts about what might be going on, or work-arounds?

jon


I can vaguely remember something like this happening back in my DBISAM days. My guess would be its something to do with buffering and a refresh before the locate will "cure" it.

Roy Lambert [Team Elevate]

Roy:

Thanks for your help!

If you meant changing the code to look like this:

             WITH dtTru.tbDetail DO BEGIN
               Refresh;
               IF Locate('ExptID;Date;SpecID', VarArrayOf([exptID, resDate, specID]), [loCaseInsensitive]) then
                  Edit
               ELSE
                  Append;

This did not help.

Jon

jon

>If you meant changing the code to look like this:
>
> WITH dtTru.tbDetail DO BEGIN
> Refresh;
> IF Locate('ExptID;Date;SpecID', VarArrayOf([exptID, resDate, specID]), [loCaseInsensitive]) then
> Edit
> ELSE
> Append;

That is what I was thinking of.

If 'ExptID;Date;SpecID' form an index it may be that its become corrupt so try repairing the table. If that doesn't help (and I suspect it won't but its easy to try) then its either the data or your logic. Since you say it works dozens of times before throwing a wobbly its probably the data.

You say resDate can be stored as a float so try TRUNCing it and see if that works, Can any of the fields be null? If so that may have an effect.

If none of the above works then if possible post code and data into the binaries so someone can have a look at it.

Roy Lambert [Team Elevate]

Turns out that I had a filter established on the table, by accident, from another previous use of the table.  So, when I did the Locate, I could not see the record, because it was filtered out.  But when I tried to add the record back in, the key collision occurred.  So, no bug, just bad code on my end.  Mystery solved.

Jon,

<< there are times when I fail to locate the record even when it is present.
The exptID value is an integer; the resDate is a date (which appears to have
an integer value), and the specID is a string.  I can be pretty sure that
the exptID and specID values match; since the resDate may be stored as
floating point, I can only report that the values appear to be integers and
that they match. >>

More than likely the issue is with the floating-point value.  I would
convert it to an Int64 or regular Integer before passing it into the Locate
in order to be assured that any "bits" aren't hanging around after the
decimal point.

Tim Young
Elevate Software
www.elevatesoft.com

jon

>Turns out that I had a filter established on the table, by accident, from another previous use of the table. So, when I did the Locate, I could not see the record, because it was filtered out. But when I tried to add the record back in, the key collision occurred. So, no bug, just bad code on my end. Mystery solved.

BTDT

Roy