Hi, Depending on the Database used, referencing the local field first (and not the remote table field) will cause the Database to skip the use of the indexes on the remote table and thus cause performance issues with the query.
This was mainly present in MS SQL as opposed to Oracle from memory. _____ Kind Regards, Carl Wilson From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Thad Esser Sent: 17 October 2014 16:34 To: arslist@ARSLIST.ORG Subject: Re: Set Field If syntax when matching on another form ** Same here, 'Field' = $Value$ is what I use, but I'm not really sure why. As Sonny from "I, Robot" (the movie) says, "It just feels wrong." :-) If the $Value$ were null, does that mess with things at all? You'd essentially be saying: where null = 'Field' . I'd assume that was handled or there'd be more issues. Just a thought. Thad On Fri, Oct 17, 2014 at 8:11 AM, LJ LongWing <lj.longw...@gmail.com> wrote: ** Rick, This is one of my personal pet peeves. I started learning database and Remedy around the same time, and all of the instruction that I ever received in the database, and what makes most sense to me is field = value This translates in a remedy world to 'Field' = $Value$ So, from this convention, I always use it as you state you prefer. Over the years, I have found TONS of different contractors that come and go use $Value$ = 'Field' and while I don't believe it causes any performance impact in any way to do it that way, it's visually unappealing to me...it took me awhile, but I eventually figured out WHY some developers produce code that looks like that. It has to do how things show up in the drop down in the Dev Studio. When building a setfield action, or push for that matter I think, when selecting fields, 'Current Form' is always the 'default', and current form is the one that produces $Value$, where 'form that it's being selected from' is not the default....so, what you get is the developer selecting the field on the current form first, and the 'other' form second, which builds a $Value$ = 'Field' type of qualification....so, while I don't think it causes any problems, it's certainly not visually appealing to me...and I agree with you that it 'should be' the other way. On Fri, Oct 17, 2014 at 8:34 AM, Rick Westbrock <rwestbr...@24hourfit.com> wrote: ** Hi all- I wanted to get feedback on something I remember learning way back in a Remedy class (pre-BMC) in Pleasanton to make sure that I am remembering correctly. I seem to recall that I was told that the best practice when writing the qualification for a Set Fields action from another form that you should use the other form’s field before the operator and the current form’s field after the operator like this: 'DEPTID' = $DeptID-New$ I thought that this was either more efficient or provided more predictable results (or maybe both). Does anyone else follow this convention? I have run across several instances in some custom workflow where that is reversed and I see $DeptID-New$ = 'DEPTID' which just feels wrong to me. Below is more detail to clarify my examples. Form A: field DeptID-New Form B: field DEPTID There is a filter on form A that does a set fields which reads its value from form B. I believe the proper syntax if I want to match the department ID fields between the forms is this: 'DEPTID' = $DeptID-New$ >From there the set fields action can copy values from the matching record in >form B into the fields of form A. Thanks, Rick _________________________ Rick Westbrock AppOps Engineer | IT Department 24 Hour Fitness USA, Inc. _ARSlist: "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"
