Perhaps I'm just overly critical. I come from a more hard-core programming background, so when I see things like this, I see it as poor design and/or lazy programming. If it's the nature of the beast, that's only because the beast was made like that, not because of technical limitations that drove this design.
If two statements are interpreted the same but don't work the same, that's a bug in my opinion. The two statements are technically equivalent and should be treated exactly the same. You're philosophy is good, I just get worked up about these kinds of things in commercial software... Lyle -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mark Lev Sent: Tuesday, March 17, 2009 11:22 AM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow?- Resolved $SERVER$ LIKE (( "%" + "Server A" ) + "%" ) doesn't work the same, it is interpreted the same; after internal processing by the run-time translator which will decipher it to become: $SERVER$ LIKE "%Server A%" As I see it: There are times the interpreter can read the qual verbatim, and other times that it needs it to be passed as a build string. I have to do this in table qualifications when I'm building and passing table quals thru Active Links. There are times when you have to put the / in a field identifier to let Remedy know it's a field identifier vs. a field value. ($/USER$) I think the situation here is the same, and sometimes Remedy needs it spelt out differently, under different situations. I don't think this is a bug, but the nature of the beast. The interpreter is a very complex system, and sometimes it has to be done in certain ways in order to function properly. My philosophy: If option A doesn't work, try option B. Thanks, Mark ________________________________ From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Tue 3/17/2009 12:41 PM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow?- Resolved ** Do you mean to say that they intended $SERVER$ LIKE (( "%" + "Server A" ) + "%" ) to work and that they intended $SERVER$ LIKE "%Server A%" NOT to work? I have a hard time buying that. At the very least, that would be considered a design flaw, since the two statements are equivalent. I suppose that a design flaw doesn't necessarily have to be considered a bug, but to try and go that route for something like this is a stretch and seems more like a thinly veiled attempt to simply deny that there's a problem. Lyle From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Meyer, Jennifer L Sent: Tuesday, March 17, 2009 10:28 AM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow?- Resolved ** It does function as designed. Jennifer Meyer ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Lyle Taylor Sent: Tuesday, March 17, 2009 11:43 AM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow?- Resolved That's GOTTA be a bug. That is (or should be) equivalent to $SERVER$ LIKE "%Server A%" I'd make them file a defect on that one if I were you. Of course they'll probably come back and say that it "functions as designed"... Lyle From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pruitt, Christopher J Sent: Tuesday, March 17, 2009 9:20 AM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow?- Resolved ** I got the solution from BMC Remedy Tech Support. Seems like they can do some good from time to time. The answer is $SERVER$ LIKE (( "%" + "Server A" ) + "%" ) Christopher Pruitt Consultant Specialist EDS, an HP Company mailto: [email protected] We deliver on our commitments so you can deliver on yours. Confidentiality Notice: This message and any files transmitted with it are intended for the sole use of the entity or individual to whom it is addressed, and may contain information that is confidential, privileged, and exempt from disclosure under applicable law. If you are not the intended addressee for this e-mail, you are hereby notified that any copying, distribution, or dissemination of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately destroy, erase, or discard this message. Please notify the sender immediately by return e-mail if you have received this e-mail by mistake. From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Scott Illari Sent: Thursday, March 12, 2009 6:56 PM To: [email protected] Subject: Re: Anyway to read the ARDBC via workflow? ** Chris, Since you are obviously having issues with the $SERVER$ identification within the escalation, I was wondering if there was something else that you could use as a qualifier (even if it isn't as clean). Just as a test, you could modify the qualification for your production server to say $DATE$ > "1/1/70" (which it will always be) and on your dev server set it up as $DATE$ < "1/1/70". Obviously, this is ugly and a BAD way to get one to fire and one not but if you need it done quickly, it will work until you can debug the $SERVER$ issue. You just need to remember to change the qualification in your def or xml file prior to migration. Scott Illari 908-601-8948 http://www.linkedin.com/in/scottillari <http://www.linkedin.com/in/scottillari> __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html_____Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
