Hi Przemek,
Okey, just to add one bit to this: This effect does
happen in non-concurrent access too, _most likely_
(but I'm not sure and see below) when the table state
(position, ordering or filtering) changes between two
stabilization calls.
So, the problem seems not just that the cache becomes
unsynced, but that the function browse.prg / FreshOrder()
becomes confused and cannot go back to its original
position, therefore the DO WHILE loop goes up to BOF().
There was a pretty simple Browse() on an indexed table
posted on the list a few years ago, which could demonstrate
the problem pretty consistently. I've attached this small
example to the list, plus find another preceding conversation
with Bill Smith about this problem. Unfortunately for me
the problem didn't surface neither with Clipper nor with
Harbour this time, but it was surely there last time.
[It depends on execution/screen response time, and some
specific but normal navigation sequence]. I just can hope
this helps.
I'm afraid that I cannot replicate it with current code.
I'm not even sure what's the exact problem.
Do you talk about the effect presented by code below?
No, the one I mentioned used to happen without any table
modification. AFAIR.
The only thing leading closer is that maybe DBEDIT() isn't
affected, only BROWSE(), where FreshOrder(), after saving
RecNo() to nRec, and doing a :refreshAll() and :forceStable(),
is not able to find the saved RecNo() in the DO WHILE loop.
This then leads to a user visible loop to BOF().
In my apps it happens a few times every day (using CA-Cl*pper,
in a custom function similar to FreshOrder()), I even have a trace
message logged every time the situation is detected and worked
around.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
