I've found a few rare instances where using direct SQL was the best way to accomplish the task at hand. It is rare.
When using direct SQL by far the biggest issue you're likely to run into is having the "T" (B, H) table be wrong between systems. The steps below are pretty simple - when I did use direct SQL I always did the following. 1.) Add field name T_table 2.) First action executed was always a set fields that used direct SQL to set the correct T-table # in the T_table field like... Select schemaid from arschema where name='HPD:Help Desk' >From there on you just used "T"+T_table in your direct SQL calls. That way it was portable across systems, etc. If you take those steps then direct SQL's downsides are mostly mitigated right from the start. There are other implications of course (E.G., exporting workflow from an Oracle database system to SQL Server database system) but the odds of running into them are low. William Rentfrow Principal Consultant, StrataCom Inc. [email protected] Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 8:51 AM To: [email protected] Subject: Re: ARERR 299 Too many levels in filter processing All valid points, however it is still a legitimate option and doesn't necessarily mean a system is hard to manage. > It's not like using an overpowered ability in a video game. Just > because you can do something doesn't necessarily mean it's a good > idea. It's just begging for some kind of data integrity issue. What if > BMC changes the underlying table structures? Plus, if you ever switch > databases, the SQL will have to change. > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Matt Worsdell > Sent: Wednesday, June 02, 2010 4:43 AM > To: [email protected] > Subject: Re: ARERR 299 Too many levels in filter processing > > I fail to see why, Direct SQL is a legitimate built in option. > > >> Hi, >> >> Direct SQL makes a system hard to manage. If there are built in > options >> other than Direct SQL, use them instead! >> >> Best Regards - Misi, RRR AB, http://www.rrr.se >> >> Products from RRR Scandinavia: >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy > logs. >> Find these products, and many free tools and utilities, at > http://rrr.se. >> >>> Another option would be to use a Direct SQL Action. >>> >>> Matt >>> >>> >>>> Hi fellow listers, >>>> >>>> This is something which i had tried. >>>> >>>> My need was to change a field value in a form after a record is >>>> submitted/modified and the record for which i need the field value >>>> change to be made is the one which got submitted/modified. >>>> >>>> So I created a filter which gets triggerred(i.e on action Submit >>>> and Modify)and then do a push field and change the value in the >>>> field > for >>>> the >>>> same form-record. >>>> >>>> Now my problem here is that as I am doing the push in the same form > for >>>> changing a value in the field, "ARERR 299 Too many levels in filter >>>> processing" occurs. I know this happens because the Push field > action >>>> ultimately triggers a submit/modify action on the same form and the >>>> filter get triggerred infinitely. >>>> >>>> Can anyone suggest me a different approach to this? >>>> >>>> Cheers :) >>>> -- >>>> View this message in context: >>>> > http://old.nabble.com/ARERR-299-Too-many-levels-in-filter-processing-t > p2 > 8750990p28750990.html >>>> Sent from the ARS (Action Request System) mailing list archive at >>>> Nabble.com. >>>> >>>> > ______________________________________________________________________ > __ > _______ >>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend >>>> wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" >>>> >>>> >>> >>> > ______________________________________________________________________ > __ > _______ >>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend >>> wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" >>> >>> -- >>> This message was scanned by ESVA and is believed to be clean. >>> >> >> > ______________________________________________________________________ > __ > _______ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend >> wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" >> >> > > ______________________________________________________________________ > __ > _______ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend > wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" > This email and any files transmitted with it are confidential and > intended solely for the individual or entity to whom they are > addressed. If you have received this email in error destroy it > immediately. > > *** Walmart > Confidential *** > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" > > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
