>Steve, you can include a tableupdate() inside your transactions. Won't that give you the data you need?
>
>HTH
>
>>I have a multi-user transaction oriented app that requires a status to be updated in one of the records. The correct update requires data from several other records in order to make a determination. Right now, both the data updates and a status update are being performed in one transaction. This makes sense but is also not working correctly as some of the data required to make the status update is not properly on the disk because it is only in buffers from the transaction and not yet committed.
>>
>>I need a good solution; two transactions? One for data and another for the status update? Or a better method of obtaining the data that may not yet be on the disk? Several SELECT statements are processed which last I knew will be drawing the data from disk and not from any potentially uncommitted transactions.
>>
>>Thanks,
>>Steve

Hi Barbara,

TableUpdate is already embedded in the transactions. My current setup looks like this;

BEGIN TRANS
FOR i = 1 to ALEN(Array of Aliases to be in the Trans)
    llValid = TableUpdate(....)
    Check llValid
ENDFOR

IF llValid
    END TRAN
ELSE
    ROLLBACK
    =TableRevert()
ENDIF

I believe that with the start of a transaction, all the data is buffered once again (not written to disk) until END TRANS is reached.  I could be wrong here but that's the way I read it so far. And that's how it seems to be working in the app otherwise my 2nd update would find the proper values and it doesn't seem to.

Here's what some additional code looks like, the above code is in a transaction class.  It has a method to fill the array of aliases so assume that the correct ones are there.

This is in the cmdSave.Click() method on the form;

llValid = oDataMgr1Class.UpdateRecord() - 1st update
IF llValid
    llValid = oDataMgr2Class.UpdateStatus() - 2nd update which requires data    
ENDIF                                         from the 1st update or other                                               tables.
IF llValid
    llValid = oTransaction.UpdateDB() - which runs the code above.
ENDIF

I'm finding that the 2nd update does not seem to have the updated data from the 1st update available which implies that the transaction buffers (even though issuing a tableupdate), have not been written to disk.  The 2nd update has SELECT statements for processing which I believe go to disk for their data.

Steve