Question : ERROR 1545 Table buffer contains uncommitted changes
I have a VFP 5.0 application running on an NT ona multiuser environment. This application accesses an Informix database table on a unix system. Clients run the application with no problems. However, every once in a while a client gets the error message 1545 – Table buffer for alias contains uncommitted changes. Here is a list of statements I have within the application that the clients run.
SET EXCLUSIVE OFF
SET REPROCESS TO 60 SECONDS
open database dbname
set multilock on
public gnConnHandle, THISERROR
gnConnHandle = 0
ON ERROR DO ERRORHAND
STORE SQLCONNECT(‘odbcbranch’, ‘xxx’,’yyy’) TO gnConnHandle
SQLSETPROP(gnConnHandle, ‘Transactions’, 2) && Manual transactions
use remview
SQLSETPROP(gnConnHandle,’TRANSACTION’,2)
cursorsetprop(“Buffering”,5,’remview’)
BEGIN TRANSACTION
tableupdate(1,.f.,’remview’)
***
*** commands to add records, update records, and delete records here to the remote table ‘remview’
***
select remview
TABLEUPDATE(.T.,.f.,’remview’)
SQLCOMMIT(gnConnHandle)
END TRANSACTION
REQUERY() && At debugging time, error occurs here.
Note that in most cases this works. Only about once or twice a week the error is displayed. The error routine displays the error number, message with an Ok button. After checking the data, I notice that some of the updates were not done on the remote view.
I have tried using the TABLEREVERT() function when the error occurs, but it only reverts the last update to the remote view. I need something to revert all the changes. In other words, I need something like a BEGIN TRANSACTION and END TRANSACTIONS with local database tables I’ve used in the past.
Any ideas?
Solution : ERROR 1545 Table buffer contains uncommitted changes
You’re using optimistic table buffering, and some (not all) of the submitted changes are being rejected because the parent records have changed since the buffer was loaded by query. You need to implement an arbiter for update collisions, and to wrap the whole sequence of updates to your remotwe views with BEGIN TRANSACTION/END TRANSACTION/ROLLBACK to handle the situation where you need to back out all table changes already committed by TABLEUPDATE() within the scope of the transaction.
Alternatively, switch to a pessimistic locking scheme, so that locks are explicitly granted before edits are started, and acquire all required locks prior to the start of any edit.
