James, This is to allow you to, for a specific field, 1) Determine programmatically if a (user or automated) transaction has attempted to change the field value or not . OR - 2) Compare what the value used to be, just before the current transaction attempted to change it, as opposed to what it is being changed to.
A good example of a use case for this is if you have a business rule requirement that neither users nor other systems or processes integrated to your form are allowed to change the Status of a record from "Assigned" to "Closed", because you want them to set it to "Resolved" first, because; 1) You have other workflow and/or SLA's and/or reports that depend on the Status.History.Resolved.TIME to be populated. OR - 2) You have a quality control process that determines that a different group of users pick up the "Resolved" records and phones the customer back to find out if they are happy with the resolution and only then is the record to be set to Status = "Closed". In either of these cases, you would implement these business rules quickly and easily through the relatively simple creation of a single Filter that Checks if 'TR.Status' = "Closed" AND 'DB.Status' != "Resolved" and returns an error. If you only use Status = "Closed" in this filter run if, you will end up with the filter getting triggered for updates that legitimately set Status = "Closed" as well. If you used an active link on Return/Menu Choice/Lose Focus of the Status field, sure, you would prevent your users from making an invalid change, but, any Filter Push Field or API integration update would still manage to do the invalid update because active links don't get triggered on that level. Sure, you can achieve the same result by adding lots of Temp fields doing set-fields from the database to get the "old DB value" for your fields, but this starts to get very messy if you; 1) Have multiple business rules that require you to do this type of comparison on multiple fields. (You could potentially end up duplicating almost all your fields on the form doing things this way). 2) Have to deal with confused user questions as to which field should we believe to hold the actual value for their reports if the fields are named similarly to avoid programmer confusion. 3) Have to add extra filters to do a relatively expensive and redundant second lookup on the database to find the "old DB value" for a field - which only serves to slow down your system. 4) Forget to change the lookup field attributes if the actual field attributes has been changed. Therefore, the need for Transactional (TR) and Database (DB) values on filter level. HTH. Best Regards, Theo -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith Sent: 08 May 2014 17:22 To: arslist@ARSLIST.ORG Subject: Transactional (TR) and Database (DB) Hi List, We can achieve things without using TR and DB values in a filter by just using Field but I do not understand why they have been developed to use? I have heard from many remedy developers like Misi and BMC who suggest not to use TR and DB in Run If qualification of a filter but why? Why it is not recommended to use TR and DB values? What if I use TR.Field=DB.Field? Will it yield a correct result? In BMC documentation also they have not given any example where they used TR and DB together in a qualification. Appreciate your thoughts! Cheers, James _______________________________________________________________________________ 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"