Sanity check

[Nancy Palmquist]

William,

Are you deleting records you are sitting on?

How are you identifying the records to delete?

If you are doing a lookup using an index and delete the record you are 
pointing at, you can not use that index as a way to getnext or getprev, 
you have to start back at the original lookup and re-establish your 
place in the index.

You can not issue WRITE in Automatic tables - that will crash indexes.

Other than that, it sounds like you are proceeding properly.  LOCK 
record, delete and write.

Usually I find that index crashes are related to DELETE or users able to 
exit with bad manners.  Automated processes are usually not susceptible 
to the user issue once you have them working properly.  But they are 
able to trash indexes that might affect your automated process.  I often 
rebuild indexes prior to automated processes to make sure everything is 
solid.

That deleted key not found error message does not close after XX 
seconds, like I was told it should years ago.  It will cause the 
processes to hang indefinitely.

But you knew all this, maybe I triggered a good memory that will help 
you fix it.

Nancy

On 6/2/2020 3:58 PM, William J. McEachran via Filepro-list wrote:
> On Tue, 2 Jun 2020 at 12:10, Fairlight via Filepro-list <
> filepro-list at lists.celestial.com> wrote:
>
>> It's the result of bad BTree+ code.
>>
>> If you go through this demo, you'll see when data needs to be split.
>> Something about it is incorrectly handled in fP, resulting in bad
>> indexes.
>>
>> https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html
>>
>>
> I got lucky and found that the nightly tar archive  had the troubled data.
> I was able to play around with it on a test system and found I could get a
> DKNF (deleted key not found) error on the data in addition to the sanity
> check
> The data is part of a simple routine that is created and used in a single
> process ... so it easily traceable.
>
> All lookups involved in record operations (creating, deleting, modifying)
> are protected (-p flag) lookups.
> Each record operations concludes with a write - 'write [lookupname''.
>   Create a record; write that record.  Delete a record; write that record.
> etc.
> The routine concludes with a 'sync'.
>
> So I can't think of anything that I've missed to cause invalid key/index
> issues.
> Did I miss something?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20200602/7d8f4995/attachment.html>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list

-- 
Nancy Palmquist         MOS & filePro Training Available
Virtual Software Systems    Web Based Training and Consulting
PHONE: (412) 835-9417           Web site:  http://www.vss3.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20200603/373b9b36/attachment.html>