Re: ARERR 299 Too many levels in filter processing
Hi Misi,Hany so on :) Although this is something which i had tried, the problem here is that although i would stop this very filter executing in this form through a 'DoNotFireMySubmitFilter'/flag , at the same time i have many other filters running on a submit again with many complex qualification and which would need to run many times in the same form. And lets just say i introduce this particular 'DoNotFireMySubmitFilter' for all the other filters on the same form it would end me up letting the other filters getting executed only once for the life time of the record. So I cant go ahead with this. I was rather trying through a set field in activelink and then doing a commit but very wierdly it closes the AR user window! Misi Mladoniczky wrote: Hi, Why not do a set-fields on the CURRENT TRANSACTION instead? If that is not possible, you can allways create a Display-Only-field called something like DoNotFireMySubmitFilter=Yes, and skip the filter if it is set. 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. 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-tp28750990p28750990.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 -- 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 -- View this message in context: http://old.nabble.com/ARERR-299-Too-many-levels-in-filter-processing-tp28750990p28776247.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
Re: ARERR 299 Too many levels in filter processing
Hi, Unions are not possible as such, but it is not hard, and quite robust, to create filters that sync the relevant data from various forms into another form, which will then have the same data as the union would have. Instead of count(*), you can create counter-records in a counter-forms that are updated by filters. Possibly with a slow safe-guard count of records done by escalations each night. It can use $LASTCOUNT$ instead of direct SQL. The end result may be even faster than the count(*) direct SQL :-) 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 situation is query unionswe have several locations in our app where we need to union several searches together into a single resultset, not possible within the Remedy architecture. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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 :) ___ 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
Re: ARERR 299 Too many levels in filter processing
Hi Folks, Having just completed a migration from Sybase to Oracle, I can tell you from personal experience that direct SQL can pose some challenges: - Literals... s are ok in Sybase, Oracle requires ''s. - Stored procedures... they work quite differently in Oracle with respect to returning results. This cost me much effort in my conversion. Although it was easier at the time to use direct SQL, I did end up converting many of the instances back to Remedy workflow when possible, even though I do not anticipate another data base platform change. :-) Hope this is helpful. Larry Larry Robinson n...@ncsu.edu Office of Information Technology NC State University 919-515-5432 Voice Raleigh, NC 27695-7109 919-513-0877 FAX On Jun 2, 2010, at 10:07 AM, William Rentfrow wrote: 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. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 8:51 AM To: arslist@ARSLIST.ORG 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. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ARERR 299 Too many levels in filter processing
Misi, I know this is an extreme examplebut one where using Remedy $LASTCOUNT$ was a HORRIBLE solution. I have a table on a form, the table has roughly 150,000 records in it. I need to do a SUM of the records in it for 3 separate columns. Doing this work via Filter and Remedy workflow, the way that Remedy did it was very simple. It took the 'Server Table Field Chunk Size' value on the Configuration tab of the server information dialog, which defaults to 1000 and performs a search on the db table the table field is based on saying 'select top 1000 ...', it finds that there are more than 1000 records, so it does it again for 'select top 2000 ...', it keeps incrementing the 'top' section by the chunk size till it finds a count that does not exceed the current chunk size. Each time it increases the number by chunk size, it of course takes longer for the query to returnin this example it needed to perform this recursive increase 150 times to get up to the 150K valueand it did this for each SUM I needed to do, which was 3...so to get the SUM of 3 columns in a table of 150K was taking about 10 min's. Converted it to select SUM() direct SQL setfields and it takes less than a second for all 3. This is a situation where deferred processing was not an option. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky Sent: Thursday, June 03, 2010 2:45 AM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing Hi, Unions are not possible as such, but it is not hard, and quite robust, to create filters that sync the relevant data from various forms into another form, which will then have the same data as the union would have. Instead of count(*), you can create counter-records in a counter-forms that are updated by filters. Possibly with a slow safe-guard count of records done by escalations each night. It can use $LASTCOUNT$ instead of direct SQL. The end result may be even faster than the count(*) direct SQL :-) 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 situation is query unionswe have several locations in our app where we need to union several searches together into a single resultset, not possible within the Remedy architecture. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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
Re: ARERR 299 Too many levels in filter processing
There are times where the OOB box of a Remedy app can't be made to work with workflow. For example - in IM 7.03 - the Transfers between groups/individuals # is wrong out of the box. Most people do not notice it because the number that is displayed on the screen in an Incident is right - but what is actually stored is wrong. The count would be updated when the Incident was opened and the change flag was reset. Our local rules dictate that any base product issues get kicked up to BMC tech support first. They actually could not find a workflow solution to this given the way the app was built. They registered a defect. I fixed it just using a direct SQL call. The other choice was ripping out a bunch of base product workflow and re-writing custom code. I haven't checked to see if this was fixed in 7.5. Anyone play with that? William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky Sent: Thursday, June 03, 2010 3:45 AM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing Hi, Unions are not possible as such, but it is not hard, and quite robust, to create filters that sync the relevant data from various forms into another form, which will then have the same data as the union would have. Instead of count(*), you can create counter-records in a counter-forms that are updated by filters. Possibly with a slow safe-guard count of records done by escalations each night. It can use $LASTCOUNT$ instead of direct SQL. The end result may be even faster than the count(*) direct SQL :-) 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 situation is query unionswe have several locations in our app where we need to union several searches together into a single resultset, not possible within the Remedy architecture. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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
Re: ARERR 299 Too many levels in filter processing
One problem with updating from LASTCOUNT would be that if you choose the escalation method, this update will happen only periodically. The only way to keep it real time is to update it with every transaction. Then in this case you would need to update this count when a record is deleted or archived. It just may get a little more complicated than you bargained for.. I don't think it will be faster than count(*). I'm not sure how all databases handle count(*) but in the case of Oracle, I think value is derived from a fast full index scan of the on a indexed field.. The ARS has Field 1 as an indexed field even if no other custom index has been added. Maybe if someone has the time to do EXPLAIN and verify this, we could know the results.. I doubt other databases would be very different from this. Try a SHOW QUERY PLAN on MS-SQL or Sybase.. And the biggest advantage of using count(*) is you can design it such that, you use it only when needed. For e.g. a tab that holds this statistic, and a tab that is seldom used. And the calculation to happen only when the user gains focus to that tab.. or maybe even a dialog box on the press of a button that displays this information.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Misi Mladoniczky Sent: Thursday, June 03, 2010 4:45 AM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing Hi, Unions are not possible as such, but it is not hard, and quite robust, to create filters that sync the relevant data from various forms into another form, which will then have the same data as the union would have. Instead of count(*), you can create counter-records in a counter-forms that are updated by filters. Possibly with a slow safe-guard count of records done by escalations each night. It can use $LASTCOUNT$ instead of direct SQL. The end result may be even faster than the count(*) direct SQL :-) 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 situation is query unionswe have several locations in our app where we need to union several searches together into a single resultset, not possible within the Remedy architecture. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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
Re: ARERR 299 Too many levels in filter processing
the way i have gotten around this problem is to have a flag field and then run your action if the flag is set to yes or no whatever the case maybe. this will get you around the loop issue. thanks Shafqat Ayaz --- On Wed, 6/2/10, Matt Worsdell m...@worsy.co.uk wrote: From: Matt Worsdell m...@worsy.co.uk Subject: Re: ARERR 299 Too many levels in filter processing To: arslist@ARSLIST.ORG Date: Wednesday, June 2, 2010, 4:42 AM 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-tp28750990p28750990.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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ARERR 299 Too many levels in filter processing
Hi, you can add new integer field X hidden and when any other workflow submit or modify in the form set this field to 0 and set a qualification in your filter X=0 and in if action push your field and push X=1 i hope this may help On Wed, Jun 2, 2010 at 10:21 AM, NNMN naveen...@gmail.com wrote: 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-tp28750990p28750990.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 -- BR, Hany ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ARERR 299 Too many levels in filter processing
Hi, Why not do a set-fields on the CURRENT TRANSACTION instead? If that is not possible, you can allways create a Display-Only-field called something like DoNotFireMySubmitFilter=Yes, and skip the filter if it is set. 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. 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-tp28750990p28750990.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 -- 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
Re: ARERR 299 Too many levels in filter processing
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-tp28750990p28750990.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
Re: ARERR 299 Too many levels in filter processing
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-tp28750990p28750990.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
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-tp28750990p28750990.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
Re: ARERR 299 Too many levels in filter processing
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:arsl...@arslist.org] On Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 4:43 AM To: arslist@ARSLIST.ORG 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-tp2 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
Re: ARERR 299 Too many levels in filter processing
The first Remedy project I worked on, I was under the tutelage of an experienced Remedy consultant. He spoke of one of his first projects, where he was tasked with making some changes to an existing Remedy (probably v2.0) system. He opened the Admin tool, and found no Active Links or Filters. The reason? The person who built the system was a DBA who had built the entire system to run on Stored Procedures. I know that using Direct SQL isn't taking it to that extreme, but the point is that you need to consider the fact that whoever follows you might not be as much of a SQL expert as you feel you are. Good code is code that someone else can pick up and go with when you're not there to explain it to them. Rick On Wed, Jun 2, 2010 at 6:09 AM, Donald Morton donald.mor...@wal-mart.comwrote: 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:arsl...@arslist.org] On Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 4:43 AM To: arslist@ARSLIST.ORG 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-tp2 8750990p28750990.htmlhttp://old.nabble.com/ARERR-299-Too-many-levels-in-filter-processing-tp28750990p28750990.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
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:arsl...@arslist.org] On Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 4:43 AM To: arslist@ARSLIST.ORG 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-tp2 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
Re: ARERR 299 Too many levels in filter processing
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. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 8:51 AM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 4:43 AM To: arslist@ARSLIST.ORG 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
Re: ARERR 299 Too many levels in filter processing
Hi, The main reason we have Direct SQL is to integrate to data from outside the Remedy-data. If you use it to access/modify Remedy-data, you will have a hart time analysing what is connected to a certain field. If you stick to Remedy-workflow, you can do a very good cross reference of how things are related in most cases. I can see a few rare instances where Direct SQL can be 1000 times faster, or where it is impossible to do with Remedy workflow. In that case you should use it, and document it well with big red capital letters... Best Regards - Misi, RRR AB, http://rrr.se 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-tp28750990p28750990.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 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
Re: ARERR 299 Too many levels in filter processing
To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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 :) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: ARERR 299 Too many levels in filter processing
Another situation is query unionswe have several locations in our app where we need to union several searches together into a single resultset, not possible within the Remedy architecture. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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 :) ___ 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
Re: ARERR 299 Too many levels in filter processing
For our complex queries we sometimes create a database view and throw a view form on top. LJ LongWing lj.longw...@gmail.com wrote: Another situation is query unionswe have several locations in our app where we need to union several searches together into a single resultset, not possible within the Remedy architecture. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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 :) __ __ ___ 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
Re: ARERR 299 Too many levels in filter processing
Union joins are indeed another great example.. Done that too once before because the joins Remedy had were slow on Sybase, and a couple of them could be re-written as a union query, so what we had done (I know its against the books) is replaced the view in the database with the new view that had that union query. This had reduced the time the ARS took to query that view from something like a few minutes to a second or so.. It was on ITSP so creating a brand new view form would need a lot of modification in workflow so we chose that approach. We had to take care though everytime someone wanted to modify that join, because it would get overwritten so we had to have the db admin recreate that union query once any modification was done.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Soria, Joe Sent: Wednesday, June 02, 2010 7:49 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing For our complex queries we sometimes create a database view and throw a view form on top. LJ LongWing lj.longw...@gmail.com wrote: Another situation is query unionswe have several locations in our app where we need to union several searches together into a single resultset, not possible within the Remedy architecture. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing To do what you need to do when all else fails or if it is impossible to do it directly.. I once had the requirement in a multi tenant environment (Submitter mode locked) to change the contents of field 2.. Only and admin user was to have the permissions to change that. How would you be able to do it from within the ARS if the workflow didn't run a Direct SQL? Other times I use it is when I'm dead sure using it would save time and that chances are bleak that the syntax would ever change.. Simple update or set statements that are hardly likely to change in syntax on that database or if you move across from databases are fine to use.. Counting records in a table is another example where I'd rather use a Direct SQL than the ARS as it would be way faster.. And what are the chances that the count(*) function would ever change when used in a select statement? So there are exceptions such as that where some things are just not possible without resorting to Direct SQL. It is like a 911 call.. Just because you have that option you do not call it for recreational purposes.. Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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 :) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
