Just catching up from last week. OK, I AM SORRY! Sheesh :) Wait there, were two other developers there between us, it must have been them :)
Ok, seriously though. interesting conversation. I honestly think tend to mix $local value$ = 'remote field' *AND* 'remote field' = $local value$. Probably for the same reason LJ mentioned, because Dev Studio sets it up that way. I find I use 'remote field' = $local value$ more often but do not get hung up doing it the other way around. As I read the qualification I find I visualize the SQL syntax in my head so more often than not I write my qualifications with column then value. Also I find I use the field list menus infrequently and free-hand many of my qualifications by using CTRL + space to auto complete. Since I am writing them out vs. choosing from a menu I tend to write it out like SQL syntax. Jason On Fri, Oct 17, 2014 at 3:16 PM, Rick Westbrock <[email protected]> wrote: > ** > > Whew, glad it wasn’t just me! I was taught by Sydney Dent probably about > ten years ago IIRC. I learned a lot from that class that I have used over > the years. It does grate on me every time I see the “backwards” syntax even > if it doesn’t affect anything except my brain. Have a great weekend all! > > > > -Rick > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Lucero, Michelle > *Sent:* Friday, October 17, 2014 3:09 PM > > *To:* [email protected] > *Subject:* Re: Set Field If syntax when matching on another form > > > > ** > > Hi, Everyone: > > > > I thought I was the only one who feels automatically driven, like some > outside force will punish me if I don’t stick to the ‘Field’ = $Value$ > syntax. I can’t write it any other way. I just can’t. Let me try, > $Valu…. Nope, can’t do it. It is literally a physical reaction in my gut > that won’t let me. > > > > With that said, I’m with Carl and Rick. > > > > I do believe that in the AR System Performance, Tuning and Troubleshooting > 3.x class that we learned to start with remote form.field first and > current.value second in qualifications. On page 238 of the manual > (copyright 1997 Remedy Corporation), although Set fields aren’t referenced > specifically, samples to promote index use are written ‘Field’ = “known > value” or ‘Field’ >= value. > > > > My two cents, > > Michelle > > > > P.S. > > *To Whomever taught this class in Dallas (Richardson), TX in August 1997* > – Thank you. This is by far the best Remedy class, I’ve ever attended. I > still use the Performance Tuning tips to this day. I still offset > escalation interval times to make sure they’re not a factor of 60. I > still use >= to give an index a starting point, etc. > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *Rick > Westbrock > *Sent:* Friday, October 17, 2014 11:11 AM > *To:* [email protected] > *Subject:* Re: Set Field If syntax when matching on another form > > > > ** > > Thanks for all the feedback. I was on MSSQL back when I learned this but > am on Oracle now so I won’t spend the time to change these when I run > across them for now. If I have time I might ping BMC Support to see if they > have a definitive answer. > > > > Carl I like that you reference local and remote forms, that’s how I > normally refer to them myself but I was afraid that some people might think > I meant a form on another server. > > > > -Rick > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *Carl > Wilson > *Sent:* Friday, October 17, 2014 9:04 AM > *To:* [email protected] > *Subject:* Re: Set Field If syntax when matching on another form > > > > ** > > 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:[email protected] <[email protected]>] *On Behalf Of *Thad > Esser > *Sent:* 17 October 2014 16:34 > *To:* [email protected] > *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 <[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_ > > > > _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_ > ------------------------------ > > This message, and any attachments, is for the intended recipient(s) only, > may contain information that is privileged, confidential and/or proprietary > and subject to important terms and conditions available at > http://www.bankofamerica.com/emaildisclaimer. If you are not the intended > recipient, please delete this message. > > _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"
