>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.
>

Hi Eric,

I am certainly open to suggestions! I can understand why it is desirable to keep TRANSACTIONS small but how then do we handle these situations?

The complete 'transaction' to me is the entire invoicing process including the Journal Entry summarizing the process.

I suppose I can code controls and have each invoice wrapped in its own transaction. Then have a separate process that gathers the data from those invoices and produces the Journal Entry in a separate Transaction. It would then be up to me to make sure that the totals agree AND that both activities occur.

I guess that means a report to which a user must react in case there are invoices that have not been 'journalized'

Even under this scenario I am faced with updating all of the individual charges with the appropriate journal ID. Hmmmmm

Thanks, Ken