If your assertion is that the AL Push is in itself a separate DB action, then yes, that would stand and the Filter actions would be separate transaction sets, subject to their own rollback. I think whether it is treated as a separate DB action is the question on the table here.
Is it processed as a separate transaction, or as a different phase within the same transaction set? I seem to recall AL Push actions kind of running in a Phase 1.5 type of way. I would suggest that Sahil export a record from forms F1 and F2 in the DB, turn on Filter/SQL logs and run the transaction to see what actually changes in the records at the DB level, comparing the post-transaction records to the saved copy. That will show whether there is anything to worry about regarding AL actions and rollback. Rick On Mon, Sep 9, 2013 at 7:13 AM, Longwing, Lj <llongw...@usgs.gov> wrote: > ** > Rick, > I believe that you are incorrect in this statement. Sahil specifically > states that the AL in question is doing a Push action. While you are > correct that actions on 'current' record are all part of a single > transaction, a Push is a separate and standalone transaction (I > believe)....so while if there are errors in AL2, the 'save' won't commit, I > believe that anything that happened with a push will have already been > committed to the DB, and not rolled back. > > > On Mon, Sep 9, 2013 at 8:10 AM, Rick Cook <remedyr...@gmail.com> wrote: > >> ** >> Guys, you're all missing something. Active Link actions that fire at the >> client level only perform actions against a displayed COPY of the record in >> the DB. Those changes aren't committed to the DB until a Save action (i.e. >> Commit Changes/Save) occurs. So from a DB perspective, there are no AL >> transactions to roll back, because they weren't sent there until a DB >> action (Modify/Create) occurs. >> >> Since all DB-based transactions can be rolled back, as you all correctly >> mentioned, the net result of that rollback is a record that, at the DB >> level, is entirely what it had been prior to the initiation of the >> transaction. What displays on the client may be different, but that, >> again, is just a copy, an overlay, if you will. >> >> Rick >> >> >> On Mon, Sep 9, 2013 at 6:52 AM, Misi Mladoniczky <m...@rrr.se> wrote: >> >>> Hi, >>> >>> I agree completely with L.J. here. Use filters. >>> >>> There is one instance though where filters do not roll back, and that is >>> if >>> you do Filter Service Calls to perform any database stuff. This in not >>> that >>> common though. >>> >>> Best Regards - Misi, RRR AB, http://rrr.se >>> >>> > The simple answer, is do it with Filters. Change your two active >>> links to >>> > be a single active link with a service action, have filters triggered >>> on >>> > service that perform the actions of both active links. >>> > >>> > This has multiple benefits, less activity between client and server, >>> which >>> > gives a better performance experience, secondly, the benefit you are >>> > looking for of transaction integrity. >>> > >>> > >>> > On Mon, Sep 9, 2013 at 7:15 AM, Sahil <pathania.sa...@gmail.com> >>> wrote: >>> > >>> >> ** >>> >> Thanks for the answer >>> >> >>> >> Then how the data integrity be maintained. If a operation is >>> performed and >>> >> change request is created along with task. This action is performed >>> by two >>> >> ALs. Now if one AL is failed then one request gets created and other >>> not. >>> >> ?? >>> >> >>> >> >>> >> regards >>> >> sahil >>> >> >>> >> >>> >> On Mon, Sep 9, 2013 at 3:10 PM, Longwing, Lj <llongw...@usgs.gov> >>> wrote: >>> >> >>> >>> ** >>> >>> No, Active links are each separate transactions, so action 1 does not >>> >>> roll back. >>> >>> >>> >>> >>> >>> On Mon, Sep 9, 2013 at 4:27 AM, Sahil Pathania >>> >>> <pathania.sa...@gmail.com>wrote: >>> >>> >>> >>>> Hello Experts, >>> >>>> >>> >>>> I just wanted to know the rollback functionality of ARS. >>> >>>> >>> >>>> I am saving request on the form. I have 3 Active links A1, A2 and >>> A3 >>> >>>> which push data to the form F1 F2 and F2. >>> >>>> >>> >>>> Once A1 Active link fires and commit the data to form F1, then >>> network >>> >>>> error comes and A2 could not fire. >>> >>>> >>> >>>> Does remedy rollback the transition on F1. >>> >>>> >>> >>>> >>> >>>> I know it happens in case of filter but not sure about Active >>> links.. >>> >>>> >>> >>>> Remedy ARS 7.6.04, oracle DB >>> >>>> >>> >>>> >>> >>>> regards >>> >>>> Sahil >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________________________________________ >>> >>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> >>>> "Where the Answers Are, and have been for 20 years" >>> >>>> >>> >>> >>> >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> *Cheers!!* >>> >> *Sahil Pathania* >>> >> >>> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >>> > >>> > >>> _______________________________________________________________________________ >>> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> > "Where the Answers Are, and have been for 20 years" >>> > >>> >>> >>> _______________________________________________________________________________ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>> "Where the Answers Are, and have been for 20 years" >>> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
