Can anyone explain to me why a find with no lock using the rowid doesn't refresh the value in the buffer even with -rereadnolock parameter enabled?
We have a number of situations where records are updated on a GUI session, and on a CHUI (barcode reader gun) session almost at the same time. For example the CHUI session requests to pick an order, the GUI session authorises the order for picking and then the operative goes and picks that order. But the CHUI session isn't getting the updated record as it still has it in the buffer from the last time it was accessed.
Progress support have told me that you need to find the record exclusive lock on the CHUI session to ensure it's not a dirty read. But we've had that code in place before and have had horrendous locking issues due to the numbers of users concurrently working.
If we change the find to use an index rather than the rowid find then it refreshes the record in the buffer. But that's not realy a workable solution either as we know we have instances of this problem, but not where.
I (still) don't exactly know why, but it is clearly stated and assumed by Progress in several papers: The -rereadnolock parameter has no affect on records that are being retrieved via RECID or ROWID.
This said, we are quite lucky with the suggested workaround to release record(s) prior to a find.
Thanks Olivier. Appreciate you getting back to me.
Strangely in my test case the release statement doesn't actually help.
I'll upload the code - runs against sports2000.
Hope this works... run t1new.p, it runs t2new.p, and then whilst it is paused you run t3new.p in a new session. Then unpause the other session.
You should change the "find no-lock" at the end of the transaction in t1-new.p by a RELEASE.
Yes that works Olivier. It's not ideal. But it works.
FIND CURRENT will also force a record re-read.
are you sure the record was written back to the database by whoever updated it?
I've created an idea to enhance this behaviour.