>
>Well, not exactly. I meant that if you do not need any buffering for other purposes, you can perfectly use TRANSACTION management without buffering. You do need a .dbc though, but that you already have if you use views. And what's more, you actually have to test your tableupdates, or trap your error and issue a rollback command in order to ... roll back to the state prior to your transaction.
>

>
>Would it not be more robust then to have a transaction _per_ invoice and eventually list those invoices that failed into a kind of an error file. That way the invoices that did make the transaction could be issued and sent. :)
>
Well, I don't know about more robust, but that is what we are doing now but without the general ledger requirement. It seems overkill to produce a journal entry for every single invoice, hence the desire for a 'summary' transaction for the whole shebang.

Perhaps what is called for here is a nested Transaction whereby the production of the invoice is a transaction within the larger transaction of producing the journal entry

Thanks,

Ken