RE: [Axapta-Knowledge-Village] SalesFormLetter.insertJournal()

[Brandon George]

And the real problem then came into play because we removed the throw statement at this point, in order for our custom code to work. We did this because we wanted to "catch and report" Invoice exceptions, and Intercompany Exceptions. So this is not a bug, but rather works fine when you keep the throw statement. Which we did Not!   Thanks for the clarification... very good to know this.   -Brandon From: Axapta-Knowledge-Village@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of John Lindsay Sent: Tuesday, September 27, 2005 2:57 PM To: Axapta-Knowledge-Village@yahoogroups.com Subject: RE: [Axapta-Knowledge-Village] SalesFormLetter.insertJournal() The ttsabort will not execute after the throw error. But after a through reading of the Axapta Transaction documentation, you will discover the true intent of the original code.   This is a nested ttsbegin. The insertJournal method starts with a ttsbegin this.allocateNumAndVoucher contains a ttsbegin this.getNumAndVoucher contains a ttsbegin this.updateNow could have a ttsbegin (method overrides FormLetter method) this.PostUpdate has a ttsbegin Nothing is committed until the final ttscommit The throw statement automatically aborts the current transaction.       ttsbegin;     numberSeq           = this.allocateNumAndVoucher();    [number, voucher]    = this.getNumAndVoucher();       if (this.updateNow())     {           this.postUpdate();           TransactionLog::create(this.transactionLogType(),this.transactionLogTxt());         ttscommit;     }     else {         throw error        ttsabort; }   Transactions from the Axapta Developers Guide A transaction is a logical unit of work. Transactions - all or nothing operations - ensure data integrity. Consider the example where you want to update all prices in the system. If the system broke down or was aborted in the middle of the operation, some records would have been updated and others not. Performing the update inside a transaction guarantees that either everything is completed or nothing is done at all. Another aspect of transactions is the capacity to lock records (or tables). If, for instance, someone is updating prices and another is using the prices at the same time, the result will be unknown (is it the price before or after the update?). Transactions ensure that, depending on the concrete alterations of the records, users get consistent data from the database (that is either all or no prices are altered). An even more difficult to manage example is the “lost update”:   Time Task A Task B 1. - - 2. FETCH Record - 3. - FETCH Record 4. UPDATE Record - 5. - UPDATE Record   In this example, task A reads a record, performs some changes and updates the record. Meanwhile task B reads the (original) record and performs some changes and updates the record afterwards. The update in task A at time 4 is lost. The solution is to lock the records (or tables) during update transactions (insert, update, and delete). This can be done by using the select forupdate statement. ttsbegin To mark the beginning of a transaction, you use the ttsbegin statement. This ensures data integrity and guarantees that all updates performed until the transaction ends (by ttscommit or ttsabort) are consistent (all or none). TransactionBegin = ttsbegin ; Starting a transaction is not meaningful if it is not ended, which is done by ttscommit or ttsabort. Therefore, there is only one coherent example illustrating those three commands. This example can be found below ttsabort. ttscommit To mark the successful end of a transaction, you use the ttscommit statement. This ends and commits a transaction. MorphX guarantees that a committed transaction will be performed according to intentions. TransactionCommit = ttscommit ; Transaction blocks may be nested Statements between ttsbegin and ttscommit may include one or more transaction blocks, like the example below. ttsbegin; // some statements ttsbegin; //statements ttscommit; ttscommit; In such cases you should note that nothing is actually committed until the successful exit from the final ttscommit. ttsabort The ttsabort command allows you to explicitly discard all changes in the current transaction. This results in the database being rolled back to the initial state: Nothing will have been changed. TransactionAbort = ttsabort ; Typically you will use this if you have detected that the user want to break the current job. Using ttsabort makes sure that the database is consistent. Note Most often the best solution is to use exception handling instead of ttsabort. The throw statement automatically aborts the current transaction.   From: Axapta-Knowledge-Village@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Brandon George Sent: Tuesday, September 27, 2005 9:37 AM To: Axapta-Knowledge-Village@yahoogroups.com Subject: RE: [Axapta-Knowledge-Village] SalesFormLetter.insertJournal()   Sabbu,    I believe you are right... that is the best approach...     From: Axapta-Knowledge-Village@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Subrahmanyam, Mamidi Sent: Tuesday, September 27, 2005 11:31 AM To: Axapta-Knowledge-Village@yahoogroups.com Subject: Re: [Axapta-Knowledge-Village] SalesFormLetter.insertJournal() Hello Brandon, I believe this should solve it......You can browse similar code on AOT\classedd..          ttsbegin;     numberSeq           = this.allocateNumAndVoucher();    [number, voucher]    = this.getNumAndVoucher();       if (this.updateNow())     {           this.postUpdate();           TransactionLog::create(this.transactionLogType(),this.transactionLogTxt());         ttscommit;     }     else {         throw error        ttsabort; // Subbu } Brandon George <[EMAIL PROTECTED]> wrote: Hello All!    I am writing custom Intercompany code. The "Out of the Box" Axapta Intercompany code works nothing like my company wants it too. Not to get to much into detail here, but that is that. So I have wrote a class, and created two tables that will handle the Intercompany Sales Order process.   Anyway there is a piece of code in the SalesFormLetter, the insertJournal() method. This method, to me, is setup strange:    ttsbegin;     numberSeq           = this.allocateNumAndVoucher();    [number, voucher]    = this.getNumAndVoucher();       if (this.updateNow())     {           this.postUpdate();           TransactionLog::create(this.transactionLogType(),this.transactionLogTxt());         ttscommit;     }     else         throw error   What is strange to me is why the ttsbegin: and ttscommit are not on the same "level" or scope? I have seen this cause issues, and cause an unbalanaced TTSbegin / TTSCommit error, which makes the user have to close out and start a new session.   This happens of course when the Else is fired because the updateNow() returns false. Reason of course is the ttscommit is never reached, I believe. I was wondering if anyone has ever had any experince with this method, and why this method must execute like it does?   thanks, Brandon   Yahoo! for Good Click here to donate to the Hurricane Katrina relief effort. Sharing the knowledge on Axapta. YAHOO! GROUPS LINKS  Visit your group "Axapta-Knowledge-Village" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.