Actually, I meant you do the set on problem but also set a display only, change flag inhibited command field.
The last filter on modify on problem has a qualification of Command field = my command and (db.firstname = firstname and db.lastname = lastname and and and) That filter then does an Execute Process clean change flag which cancels the update. Turns out that that idea is wrong. The Set-Change-Flag process is only available in Active Links and not in Filters. I guess once the Modify is initiated there's no way to stop it. So, a slight change then more in line with what you are thinking Two DO fields on problem; one to initiate the command, the second to see if the data has changed Set fields from SQL Select count(*) from user form where key = key and firstname = firstname and last name = last name etc The next filter sets the firstname, lastname, etc and has the qual of DO field = 0 Both the DO fields have Disable change flag set. You can still run into filter limits because all transactions under a single escalation are counted together. There is always the use of the Service which if it diagnoses a change could then push to itself. Sorry. I though you could cancel an update but apparently not once the dirty bit is set. Cheers Ben -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: February-10-12 19:25 To: arslist@ARSLIST.ORG Subject: Re: Escalation trigger filters without modifying records? Thank you all for the feedback. I should have also mentioned that modifying the records for "no reason" is really at the core of the issue, so the "modified by" field is a side-issue. Also, normalization versus denormalization-- it is confusing but as far as I understand it you would normally start with normalized data and then add denormalization for performance or, in this case, because that's what AR System encourages. That is my goal, to have a fully normalized data structure with the added denormalized data "on top". So I'd like to try to run through what Ben has suggested here on an example, and see if I understand what he's saying. Let's say I have a Problem Ticket form: FirstName LastName UserID(ForeignKey) ProblemInfo And I have a User form with: UserID(PrimaryKey) FirstName LastName So if I follow Ben's suggestion I would add some logic on the Problem Ticket form to "diagnose" whether the Userinfo has changed instead of just arbitrarily doing a "set" operation for all records. So I create two display-only fields on Problem Ticket and set Disable Change Flag = True? FirstName LastName UserID ProblemInfo ZTrigger (display only, disable change flag) ZCompare (display only, disable change flag) So my escalation can set ZTrigger = $timestamp$ to trigger the on-modify filters without actually modifying the record? Assuming that is technically possible, then I could have On-Modify filters that do the "diagnosis": Do a set-fields ZCompare = Firstname (from User Form). Then another filter w/ qual: If ZCompare != DB.FirstName, set-fields Firstname = ZCompare. Then do the same thing with LastName via a filter guide, I suppose. Fred's suggestion of triggering updates on the source-side (User) actually seems to make the most sense, although David suggests that might be a performance problem. If a single update to a user record has to go update 5,000 records across multiple forms, that might be a problem. Although that could be changed to just run off-peak anyway via an escalation (but now you can't compare DB to TR and so you'd have to store previous values in extra fields, or a set a generic sync flag field? Doh!). I think I must just have a tendency to try to keep workflow self-contained and not "creep" onto other forms. Actually, that is not the only reason, I just remembered that, quite often, we allow arbitrary input and then we want to link it later. For instance with the Problem Ticket we might take Firstname and Lastname before there is ever a User account, so UserID is NULL. The only way to resolve these is to have an escalation attempt to link it to the User record at a later time (via first and last name). So if Ben's suggestion works, that would be nice to avoid the excessive updates. I'm also thinking of another workflow where a form "waits" for a record to be created in another system. Right now I have an escalation trigger a modify to perform a "check" to see if that record has been created yet in a view form, and once it finds a match it moves on to the next task. Again that would be nice to avoid modify updates for just a "check". I think I'm done rambling, thank you again I'll post back if I successfully can trigger the on-modify filters via an escalation without actually modifying the records using the tips Ben suggested. Brien On 2/10/2012 8:12 AM, Ben Chernys wrote: > What Fred is saying is avoid the escalation by including your > normalization at time of save or in his second case at time of save of > another form (with a non AR_ESCALATOR user). (Sorry Fred. Just > wanted to make that a bit clearer). > > The ONLY way to modify a record without changing the fields modifier > and modified time is through the Merge API which is not doable by > workflow. It is certainly doable with other methods like a > Meta-Update script, your own code in a "binary" etc. > > ARS always performs the save when fields that set the "dirty bit" are > set - even if they are set to the same value. > Ie: db.f = 1; set fields f = 1; modification made. > > By rewriting your filters to diagnose that there are no changes rather > than arbitrarily setting values to equal values, and by turning off > the "Modified" flag on your trigger field, or by turning off the > dirty bit at the end (a new filter that compares the fields you are > modifying with the db.fields and if no changes turns off the dirty bit). > > This would still leave AR_ESCALATOR on those records that really were > changed but (presumably) not on all records. > > Meta-Update by default does not issue the modify when nothing has changed. > So certainly you would be able to do this with Meta-Update no problem. > You also do not run into the filter limit. > > Cheers > Ben Chernys > > Senior Software Architect > Software Tool House Inc. > > Canada / Deutschland / Germany > Mobile: +49 171 380 2329 GMT + 1 + [ DST ] > Email: Ben.Chernys _AT_ softwaretoolhouse.com > Web: www.softwaretoolhouse.com > > Check out Software Tool House's free Diary Editor. > > Meta-Update, our premium ARS Data tool, lets you automate your > imports, migrations, in no time at all, without programming, without > staging forms, without merge workflow. > http://www.softwaretoolhouse.com/ > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W > Sent: February-10-12 04:03 > To: arslist@ARSLIST.ORG > Subject: Re: Escalation trigger filters without modifying records? > > If your "normalization" happens on every save of the record then are > you having to run thru them on a schedule to update them because > something somewhere else changed? > > i.e. If you are setting a Name field in Form AAA on save, are you > trying to keep that Name field in sync with a Name somewhere else (like on Form BBB)? > I would look at trying to detect when the source of Name (Form BBB) is > changed and force the related records (Form AAA) to update at that time. > > Fred > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle > Sent: Thursday, February 09, 2012 6:13 PM > To: arslist@ARSLIST.ORG > Subject: Escalation trigger filters without modifying records? > > I've got a lot of filters that do some "normalization" by setting some > key fields via a lookup. This might be a bad idea, but I generally > create escalations that do some tidying up-- they just blast through > all the records and update a trigger field to trigger the modify filters. > Having all the records "last modified by AR_ESCALATOR" is starting to > irritate some of my colleagues, so I'd like to stop doing this. Any > thoughts? I've tried several ways to get an escalation to trigger the > modify actions without actually modifying the record-- without any success. > I also definitely do not want to duplicate the code in the modify > actions and copy them into the escalation. > > Thanks! > > Brien > > ______________________________________________________________________ > ______ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend > wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
