Although I think what you are proposing is doable, I don't think that this is really the intended use of a transaction. A transaction is supposed to define a singular unit, like debit/credit on an account, for example. If you read on transactions you'll start hearing a lot about atomicity and ACID properties, making transactions short and reducing dependencies, etc. You are really looking for a buffering scheme - I think you could pretty much accomplish most of this with TABLEUPDATE if you really wanted to do it in batch. I'd personally think that each individual post would get wrapped in a transaction to avoid an indeterminate state.

>>
>>Ken, you network may only allow so many "locks" - I'm not sure if this is important in TRANSACTION / COMMIT because I don't know how it's implemented - but might be worth a quick look esp. if you are running Novell, which is limited to about 2000
>>Regards
>
>Hi David,
>
>Thanks. It is Novell and I'll have the admistrator check it out.
>
>I read up a little on Transactions in the Developer Guide and it mentions that it works by making the updates in cache then actually updating the tables after the END TRANSACTION. So maybe there is insufficient space to cache all of the transactions. Hmmmmmm.
>
>Ken