Subject RE: [IBO] TIBOQuery locking on edit
Author Jason Wharton
Greg,
 
You might also want to spend some time going through the Optimizing Queries and Transaction in the ibo5\docs\ folder.  It has some good information on how IBO handles cached updates and pessimistic locking, etc.
 
Jason


From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
Sent: Wednesday, April 24, 2019 11:03 AM
To: IBObjects@yahoogroups.com
Subject: [IBO] TIBOQuery locking on edit

In the recent past we migrated to using IBO instead of BDE for data access.  We converted TQuery components to TIBOQuery components.  When the TQuery with RequestLive set to True, when it is put in to edit mode, at certain points does a check to see if the thing you are editing has been changed and if it had changed since you put it in to edit mode then it throws an error.  I believe the check happened when you try and Post the change but I could be wrong about the timing.  It appears the TIBOQuery component, with RequestLive set to True, will lock the row instead.  One thing about this change is that it changes "who" is getting blocked.  In BDE the user who Posts last gets an error.  But in IBO, the user who goes in to Edit mode first gets the lock.  I can see merits to this difference over the BDE way of doing things.  My problem is though that I am getting "silent" failures, whereas previously users were getting an error.  I have a table / screen where a user can put a TIBOQuery in to Edit mode by typing in a modification to a data aware edit box.  This leaves the row in question locked until the user leaves that edit box.  I have another table / screen that when posting changes to it's records can cause a trigger to fire that updates values in the first table.  If screen / table 1 went in to edit mode, then if screen / table 2 performed a change that caused a trigger to fire that updated that row in table 1, the change on table 2 would happen and table 1 would be modified by the trigger.  Then when the user on screen/table 1 left that field the change they made would attempt to post but would fail saying another user had changed the record.  Now though, the user in screen/table 1 puts a lock on the row, and when the change is made to screen/table 2 the change is committed, the trigger probably fires but silently fails to perform its action because the row it is trying to update is locked by another user (no error shown).  This is causing data that is supposed to be synchronized to now be sometimes be "out of date" and because no error is thrown our software can't detect anything is wrong.

Is there a way to make TIBOQuery with RequestLive set to true and TIBOTable to act the same way as the BDE did as far as not locking the row and performing a check at time of posting the changes?