I guess It might depend on your background too. If you come from php or some other coding language it would actually make more sense to do: $status$='status' Since variables begin by $ and strings by '. And there doing the opposite would actually trigger an error so your brain is "hard-coded" ^_^
Anyway, good to know the right way to do things in all languages. Mobilis in Mobile. > Le 18 oct. 2014 à 00:27, Carl Wilson <carlbwil...@gmail.com> a écrit : > > ** > In addition to this, when I was with Column we did a lot of testing of these > types of queries against different DB's for performance tuning - so although > some people do say that it does not make a difference we did prove that the > indexes were skipped in certain instances on different DB's. > When I made my logging application, I added a tab that showed where the > qualifications are "backwards" in their logic due to the above. Other third > party logging tools also do the same where they indicate that the query > "should" be reversed for optimal performance. > > Always a good rule of thumb to stick to the rule of referencing the external > (or non local/remote) table field first in the qualification, although this > may be now mitigated in the latest versions of the DB's used [good coding > practise] J > > > Kind Regards, > > Carl Wilson > > > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock > Sent: 17 October 2014 23:17 > To: arslist@ARSLIST.ORG > Subject: Re: Set Field If syntax when matching on another form > > ** > 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:arslist@ARSLIST.ORG] On Behalf Of Lucero, Michelle > Sent: Friday, October 17, 2014 3:09 PM > To: arslist@ARSLIST.ORG > 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:arslist@ARSLIST.ORG] On Behalf Of Rick Westbrock > Sent: Friday, October 17, 2014 11:11 AM > To: arslist@ARSLIST.ORG > 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:arslist@ARSLIST.ORG] On Behalf Of Carl Wilson > Sent: Friday, October 17, 2014 9:04 AM > To: arslist@ARSLIST.ORG > 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: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_ > _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_ > _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"
