<div dir="ltr">Thanks all for the great replies and the memory tweaks.<div>This is one of those "how the heck are they doing this" problems.</div><div>I can't make it happen. I do suspect users "doing something" but I should be able to catch, and stop, whatever they're doing (and it sure isn't obvious ). </div><div><br></div><div>I've got work-a-round and this won't be a problem for the client going forward. But I'd like to solve it 'properly'.</div><div>Can't solve it until I can duplicate it.</div><div><br></div><div>I'll keep plugging away as time permits (the client lost interest at "I've got a work-a-round") and I'll keep the list informed.</div><div>--<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Bill McEachran</div><div><font size="1"><a href="mailto:bill.mceachran@gmail.com" target="_blank">bill.mceachran@gmail.com</a> 289-356-4406</font></div><div></div></div><div><br></div><div><br></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 3 Jun 2020 at 14:52, Nancy Palmquist via Filepro-list <<a href="mailto:filepro-list@lists.celestial.com">filepro-list@lists.celestial.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">William,<br>
<br>
Are you deleting records you are sitting on?<br>
<br>
How are you identifying the records to delete?<br>
<br>
If you are doing a lookup using an index and delete the record you are <br>
pointing at, you can not use that index as a way to getnext or getprev, <br>
you have to start back at the original lookup and re-establish your <br>
place in the index.<br>
<br>
You can not issue WRITE in Automatic tables - that will crash indexes.<br>
<br>
Other than that, it sounds like you are proceeding properly. LOCK <br>
record, delete and write.<br>
<br>
Usually I find that index crashes are related to DELETE or users able to <br>
exit with bad manners. Automated processes are usually not susceptible <br>
to the user issue once you have them working properly. But they are <br>
able to trash indexes that might affect your automated process. I often <br>
rebuild indexes prior to automated processes to make sure everything is <br>
solid.<br>
<br>
That deleted key not found error message does not close after XX <br>
seconds, like I was told it should years ago. It will cause the <br>
processes to hang indefinitely.<br>
<br>
But you knew all this, maybe I triggered a good memory that will help <br>
you fix it.<br>
<br>
Nancy<br>
<br>
On 6/2/2020 3:58 PM, William J. McEachran via Filepro-list wrote:<br>
> On Tue, 2 Jun 2020 at 12:10, Fairlight via Filepro-list <<br>
> <a href="mailto:filepro-list@lists.celestial.com" target="_blank">filepro-list@lists.celestial.com</a>> wrote:<br>
><br>
>> It's the result of bad BTree+ code.<br>
>><br>
>> If you go through this demo, you'll see when data needs to be split.<br>
>> Something about it is incorrectly handled in fP, resulting in bad<br>
>> indexes.<br>
>><br>
>> <a href="https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html" rel="noreferrer" target="_blank">https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html</a><br>
>><br>
>><br>
> I got lucky and found that the nightly tar archive had the troubled data.<br>
> I was able to play around with it on a test system and found I could get a<br>
> DKNF (deleted key not found) error on the data in addition to the sanity<br>
> check<br>
> The data is part of a simple routine that is created and used in a single<br>
> process ... so it easily traceable.<br>
><br>
> All lookups involved in record operations (creating, deleting, modifying)<br>
> are protected (-p flag) lookups.<br>
> Each record operations concludes with a write - 'write [lookupname''.<br>
> Create a record; write that record. Delete a record; write that record.<br>
> etc.<br>
> The routine concludes with a 'sync'.<br>
><br>
> So I can't think of anything that I've missed to cause invalid key/index<br>
> issues.<br>
> Did I miss something?<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <<a href="http://mailman.celestial.com/pipermail/filepro-list/attachments/20200602/7d8f4995/attachment.html" rel="noreferrer" target="_blank">http://mailman.celestial.com/pipermail/filepro-list/attachments/20200602/7d8f4995/attachment.html</a>><br>
> _______________________________________________<br>
> Filepro-list mailing list<br>
> <a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
> Subscribe/Unsubscribe/Subscription Changes<br>
> <a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" rel="noreferrer" target="_blank">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
<br>
-- <br>
Nancy Palmquist MOS & filePro Training Available<br>
Virtual Software Systems Web Based Training and Consulting<br>
PHONE: (412) 835-9417 Web site: <a href="http://www.vss3.com" rel="noreferrer" target="_blank">http://www.vss3.com</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mailman.celestial.com/pipermail/filepro-list/attachments/20200603/373b9b36/attachment.html" rel="noreferrer" target="_blank">http://mailman.celestial.com/pipermail/filepro-list/attachments/20200603/373b9b36/attachment.html</a>><br>
_______________________________________________<br>
Filepro-list mailing list<br>
<a href="mailto:Filepro-list@lists.celestial.com" target="_blank">Filepro-list@lists.celestial.com</a><br>
Subscribe/Unsubscribe/Subscription Changes<br>
<a href="http://mailman.celestial.com/mailman/listinfo/filepro-list" rel="noreferrer" target="_blank">http://mailman.celestial.com/mailman/listinfo/filepro-list</a><br>
</blockquote></div>