Steve,

I *haven't done it myself, but I do think that that is one very important purpose of nested transactions - to let data get UPDATED in tables so that it is available to SUBSEQUENTLY-issued accesses against that data.
You should be able to do pretty much whatever you need.

good luck,
Jim N

>>>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
>>
>>You can nest up to 5 levels of transactions. It sounds like this is what you want to do.
>>
>>Ed
>
>I know that you can nest up to five levels but none of that data I believe is written to disk either until all are committed. This leaves the same problem intact.
>
>BEGIN TRANS 1
> some update code
>
> BEGIN TRANS 2
> some status code update
> END TRANS
>END TRANS
>
>If I'm wrong on that, then it would be the way to go but I think that
>the data from trans 1 is not yet available to the select statements that
>will be processed to determine the second update.
>
>Thanks,
>Steve