Information générale
Catégorie:
Codage, syntaxe et commandes
>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
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement