Hi Ken,

To your question 1, let me tell you that tableupdate is not even necessary with transactions. If you have an error writing something away _during_ the transaction, you ROLLBACK and your db is in the state before you started the transaction.

To your question 2: I dunno. I've never had a problem, and I've had documents with hundreds of lines to be posted against inventory and A/R. You _are_ talking about an order of magnitude more.

HTH,

Marc



>I need some clarification/direction on the use of Transaction Processing in VFP6.
>
>Assume thousands of items to be consolidated onto hundreds of invoices under the auspices of a single invoicing process and that the entire process is to be summarized into a general ledger entry consisting of a debit to A/R and several credits to various revenue accounts.
>
>Transaction Processing seems just the ticket. I set table buffering on the applicable tables and proceed to insert records into the invoice view and the general ledger view while at the same time updating the charge records with the invoice_ID and general ledger ID.
>
>When all charge records have been processed I initiate A Transaction and proceed to attempt TABLEUPDATE on all of the views. If all TABLEUPDATES are successful, the transaction is completed. Otherwise, all view are rolled back and I can try again later.
>
>Am I correct in assuming that ANY failure of any record to update properly will cause TABLEUPDATE to return .F. OR, will TABLEUPDATE return .T. if some of the records are updated ?
>


>Question 2, is there a practical limit to the volume of recordes included in the transaction ?
>
>Thanks,
>
>Ken