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 <[email protected]> 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 <[email protected]> > 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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
