AW: EXTERNAL: Application-Query-Delete-Entry
Dave, it’s normal behavior of an oracle database to not release any space if you delete records. It’s also not an issue specific to LOBs. But there are ddl commands to reorganize the table online to reclaim “wasted” space. alter table T63 enable row movement; alter table T63 shrink space cascade; and don’t forget to rebuild the indexes as well. Regards Conny Von: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] Im Auftrag von Dave Barber Gesendet: Donnerstag, 1. September 2016 15:39 An: arslist@ARSLIST.ORG Betreff: Re: EXTERNAL: Application-Query-Delete-Entry ** All, Many thanks - I'm going with the archive/delete from source option. The messages form is already down to a "manageable" number of records (2 million, we're sending about 10,000 messages per day!) Interesting aside - this hasn't actually freed up any space on the database. Its apparently something in the nature of LOBs (which are used in the To/Cc/Bcc fields) which means that Oracle doesn't release the space as you may expect. One of our DBAs has some thoughts on resolving this that involves creating a copy of T63, copy records over, then replace T63 with the copy. That leaves me feeling a little uncomfortable with the H/B tables and database integrity. Regards Dave On 31 August 2016 at 17:22, Brittain, Mark <mbritt...@navisite.com<mailto:mbritt...@navisite.com>> wrote: ** Sort of like Todd says, I had a similar situation but with a much larger form in 6.3 using archive, delete from source. What I did was a little bit each night changing the archive query each morning sort of like this ‘Create Date’ < $DATE$ - (60 * 60 *24 * 720) ‘Create Date’ < $DATE$ - (60 * 60 *24 * 713) ‘Create Date’ < $DATE$ - (60 * 60 *24 * 706) Took me about a month to get where I wanted to be. Slow but if you’re worried about performance, that works Mark From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Dave Barber Sent: Wednesday, August 31, 2016 2:55 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: EXTERNAL: Application-Query-Delete-Entry ** Todd, Regardless of the method used (archiving, or application-query-delete-entry), I realised this could be a problem - I've already (manually) cleared down the email messages form. Awkward though, as I had set it to run overnight and delete a small data set (should have only been 21 records), and it doesn't appear to have done anything. Regards Dave On 30 August 2016 at 16:39, Arner, Todd <tar...@glhec.org<mailto:tar...@glhec.org>> wrote: ** Be cautious when adding the archiving, especially if the first night it runs if it will be trying to archive a large number of records. We ran into some major performance issues. We ended up slow adjusting the archive criteria so that a smaller amount of records were archived each night until the back log was processed. Todd Arner Great Lakes From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 10:29 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: EXTERNAL: Application-Query-Delete-Entry ** I had completely forgotten about the archiving options (my bad, etc. etc) Much appreciated, I've put that in place to run overnight, with luck it should work! On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com<mailto:john.j.rei...@lmco.com>> wrote: ** Dave, Have you tried using the Archive function to just “Delete from Source”? It sets up just like an escalation with a timing cycle to run it and a Qualification to select which data to delete. Thank you, --- John J. Reiser Building 760-J202 Remedy AR System Developer Senior Software Development Analyst Lockheed Martin - MST Moorestown Region The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 9:49 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: EXTERNAL: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The
Re: Application-Query-Delete-Entry
Doug, Much appreciated; don't recall having seen the / (or \) reference before. The archiving option is working perfectly. Regards Dave On 31 August 2016 at 20:01, Mueller, Doug <doug_muel...@bmc.com> wrote: > ** > > Dave, > > > > All the other suggestions about archive and escalations and the like apply > as different ways to get this done. > > > > But, to tell you why what you were doing below doesn’t work and to help > any other users having issues with qualifiers in run processes. > > > > Use $\TIMESTAMP$ instead of $TIMESTAMP$ in the qualifier. > > > > The extra \ is to escape interpretation of the value. As entered, the > TIMESTAMP keyword is expanded as it is processing rather than being a > keyword so you get the syntax error. Putting in the \ will keep it a > keyword and your qualifier should do what you wanted. This syntax is > needed only for situations where you are putting a qualifier inside the > logic of an operation (not in the RunIF but in places where normally the > keyword is expanded during as the operation proceeds). > > > > > > (and I think it is a \. If not, try /…..) > > > > NOTE: Still using the archive or escalation or other mechanism may be the > best answer for your specific situation. I just wanted to explain the > reason that you were having the issue with the qualifier below. > > > > Doug Mueller > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 6:49 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Application-Query-Delete-Entry > > > > ** > > All, > > I'm trying to figure out the syntax required for > Application-Query-Delete-Entry (Server is running ARS 7.5) > > Trying to keep an "archive" of emails - we have a requirement to keep 6 > months worth in the system (audit trail, proof of sending, etc.), and the > form was actually turning out to be the largest on the system (over 7 > million records - I manually deleted the older ones via the user tool, that > is not fun!). > > In an active link, just trying a simple > > $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" > '3' < ($TIMESTAMP$ - (86400 * 75)) > > The 75 is related to a test system and the data that is on it (would > obviously be changed on live). The query itself is fine against the email > messages form, it just comes up with a qualification error when run via the > active link. > > Any suggestions? I could try an alternative using > Application-Delete-Entry and table walking, but that'll > be horrendously inefficient in comparison to Application-Query-Delete- > Entry. > > Regards > > Dave Barber > > _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"
Re: EXTERNAL: Application-Query-Delete-Entry
All, Many thanks - I'm going with the archive/delete from source option. The messages form is already down to a "manageable" number of records (2 million, we're sending about 10,000 messages per day!) Interesting aside - this hasn't actually freed up any space on the database. Its apparently something in the nature of LOBs (which are used in the To/Cc/Bcc fields) which means that Oracle doesn't release the space as you may expect. One of our DBAs has some thoughts on resolving this that involves creating a copy of T63, copy records over, then replace T63 with the copy. That leaves me feeling a little uncomfortable with the H/B tables and database integrity. Regards Dave On 31 August 2016 at 17:22, Brittain, Mark <mbritt...@navisite.com> wrote: > ** > > Sort of like Todd says, I had a similar situation but with a much larger > form in 6.3 using archive, delete from source. What I did was a little bit > each night changing the archive query each morning sort of like this > > > > ‘Create Date’ < $DATE$ - (60 * 60 *24 * 720) > > ‘Create Date’ < $DATE$ - (60 * 60 *24 * 713) > > ‘Create Date’ < $DATE$ - (60 * 60 *24 * 706) > > > > Took me about a month to get where I wanted to be. Slow but if you’re > worried about performance, that works > > > > Mark > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Wednesday, August 31, 2016 2:55 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: EXTERNAL: Application-Query-Delete-Entry > > > > ** > > Todd, > > Regardless of the method used (archiving, or application-query-delete-entry), > I realised this could be a problem - I've already (manually) cleared down > the email messages form. > > Awkward though, as I had set it to run overnight and delete a small data > set (should have only been 21 records), and it doesn't appear to have done > anything. > > Regards > > Dave > > > > On 30 August 2016 at 16:39, Arner, Todd <tar...@glhec.org> wrote: > > ** > > Be cautious when adding the archiving, especially if the first night it > runs if it will be trying to archive a large number of records. We ran > into some major performance issues. We ended up slow adjusting the archive > criteria so that a smaller amount of records were archived each night until > the back log was processed. > > > > Todd Arner > > Great Lakes > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 10:29 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: EXTERNAL: Application-Query-Delete-Entry > > > > ** > > I had completely forgotten about the archiving options (my bad, etc. etc) > > Much appreciated, I've put that in place to run overnight, with luck it > should work! > > > > On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com> wrote: > > ** > > Dave, > > Have you tried using the Archive function to just “Delete from Source”? > > It sets up just like an escalation with a timing cycle to run it and a > Qualification to select which data to delete. > > > > Thank you, > > --- > John J. Reiser > Building 760-J202 > Remedy AR System Developer > > Senior Software Development Analyst > Lockheed Martin - MST Moorestown Region > The star that burns twice as bright burns half as long. > Pay close attention and be illuminated by its brilliance. - paraphrased by > me > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 9:49 AM > *To:* arslist@ARSLIST.ORG > *Subject:* EXTERNAL: Application-Query-Delete-Entry > > > > ** > > All, > > I'm trying to figure out the syntax required for > Application-Query-Delete-Entry .... (Server is running ARS 7.5) > > Trying to keep an "archive" of emails - we have a requirement to keep 6 > months worth in the system (audit trail, proof of sending, etc.), and the > form was actually turning out to be the largest on the system (over 7 > million records - I manually deleted the older ones via the user tool, that > is not fun!). > > In an active link, just trying a simple > > $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" > '3' < ($TIMESTAMP$ - (86400 * 75)) > > The 75 is related to a test system and the data that is on it (would > obviously be changed on live). The query itself is fine against the email > messages form, it just co
Re: Application-Query-Delete-Entry
I learn something new Thanks From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Wednesday, August 31, 2016 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry ** Fred, The key is to not have the keyword interpreted as you prepare the command line to be run. As entered by Dave, there were no “” around the keyword – as there should not be to work as a keyword. But, as it was just the keyword, it was being expanded as the run process was being created rather than staying as a keyword to be processed in the qualifier as the command ran. It would expand into the timestamp value. Without quotes, you get one error – a syntax error. With quotes you get another syntax error of a character string being subtracted by a number (or if it auto converts, likely you get the month as an integer and that is involved in the arithmetic operation). The key is to keep it from expanding as the command line is being built so that it is a true keyword when the command is run and it is passed on to the process. Doug From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, August 31, 2016 12:28 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Application-Query-Delete-Entry ** Would using the Slash (and no Double Quotes) make the keyword be treated as the number value in the Run Process? '3' < (1472670600 - (86400 * 75)) I was thinking he was getting the qualification error when the Active Link fires because of the expansion and no double quotes '3' < ($TIMESTAMP$ - (86400 * 75)) Expands to something (assuming US format) which the Run Process command wouldn’t understand '3' < (08/31/2016 2:10:00 PM - (86400 * 75)) (8 divided by 31 divided by 2016 then error as it doesn’t know what to do with the 2 ) With Double Quotes around the keyword ( “$TIMESTAMP$” ) it would expand to '3' < (“08/31/2016 2:10:00 PM” - (86400 * 75)) Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Wednesday, August 31, 2016 2:01 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Application-Query-Delete-Entry ** Dave, All the other suggestions about archive and escalations and the like apply as different ways to get this done. But, to tell you why what you were doing below doesn’t work and to help any other users having issues with qualifiers in run processes. Use $\TIMESTAMP$ instead of $TIMESTAMP$ in the qualifier. The extra \ is to escape interpretation of the value. As entered, the TIMESTAMP keyword is expanded as it is processing rather than being a keyword so you get the syntax error. Putting in the \ will keep it a keyword and your qualifier should do what you wanted. This syntax is needed only for situations where you are putting a qualifier inside the logic of an operation (not in the RunIF but in places where normally the keyword is expanded during as the operation proceeds). (and I think it is a \. If not, try /…..) NOTE: Still using the archive or escalation or other mechanism may be the best answer for your specific situation. I just wanted to explain the reason that you were having the issue with the qualifier below. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 6:49 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _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"
Re: Application-Query-Delete-Entry
Fred, The key is to not have the keyword interpreted as you prepare the command line to be run. As entered by Dave, there were no “” around the keyword – as there should not be to work as a keyword. But, as it was just the keyword, it was being expanded as the run process was being created rather than staying as a keyword to be processed in the qualifier as the command ran. It would expand into the timestamp value. Without quotes, you get one error – a syntax error. With quotes you get another syntax error of a character string being subtracted by a number (or if it auto converts, likely you get the month as an integer and that is involved in the arithmetic operation). The key is to keep it from expanding as the command line is being built so that it is a true keyword when the command is run and it is passed on to the process. Doug From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, August 31, 2016 12:28 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry ** Would using the Slash (and no Double Quotes) make the keyword be treated as the number value in the Run Process? '3' < (1472670600 - (86400 * 75)) I was thinking he was getting the qualification error when the Active Link fires because of the expansion and no double quotes '3' < ($TIMESTAMP$ - (86400 * 75)) Expands to something (assuming US format) which the Run Process command wouldn’t understand '3' < (08/31/2016 2:10:00 PM - (86400 * 75)) (8 divided by 31 divided by 2016 then error as it doesn’t know what to do with the 2 ) With Double Quotes around the keyword ( “$TIMESTAMP$” ) it would expand to '3' < (“08/31/2016 2:10:00 PM” - (86400 * 75)) Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Wednesday, August 31, 2016 2:01 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: Application-Query-Delete-Entry ** Dave, All the other suggestions about archive and escalations and the like apply as different ways to get this done. But, to tell you why what you were doing below doesn’t work and to help any other users having issues with qualifiers in run processes. Use $\TIMESTAMP$ instead of $TIMESTAMP$ in the qualifier. The extra \ is to escape interpretation of the value. As entered, the TIMESTAMP keyword is expanded as it is processing rather than being a keyword so you get the syntax error. Putting in the \ will keep it a keyword and your qualifier should do what you wanted. This syntax is needed only for situations where you are putting a qualifier inside the logic of an operation (not in the RunIF but in places where normally the keyword is expanded during as the operation proceeds). (and I think it is a \. If not, try /…..) NOTE: Still using the archive or escalation or other mechanism may be the best answer for your specific situation. I just wanted to explain the reason that you were having the issue with the qualifier below. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 6:49 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _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"
Re: Application-Query-Delete-Entry
Would using the Slash (and no Double Quotes) make the keyword be treated as the number value in the Run Process? '3' < (1472670600 - (86400 * 75)) I was thinking he was getting the qualification error when the Active Link fires because of the expansion and no double quotes '3' < ($TIMESTAMP$ - (86400 * 75)) Expands to something (assuming US format) which the Run Process command wouldn’t understand '3' < (08/31/2016 2:10:00 PM - (86400 * 75)) (8 divided by 31 divided by 2016 then error as it doesn’t know what to do with the 2 ) With Double Quotes around the keyword ( “$TIMESTAMP$” ) it would expand to '3' < (“08/31/2016 2:10:00 PM” - (86400 * 75)) Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Wednesday, August 31, 2016 2:01 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry ** Dave, All the other suggestions about archive and escalations and the like apply as different ways to get this done. But, to tell you why what you were doing below doesn’t work and to help any other users having issues with qualifiers in run processes. Use $\TIMESTAMP$ instead of $TIMESTAMP$ in the qualifier. The extra \ is to escape interpretation of the value. As entered, the TIMESTAMP keyword is expanded as it is processing rather than being a keyword so you get the syntax error. Putting in the \ will keep it a keyword and your qualifier should do what you wanted. This syntax is needed only for situations where you are putting a qualifier inside the logic of an operation (not in the RunIF but in places where normally the keyword is expanded during as the operation proceeds). (and I think it is a \. If not, try /…..) NOTE: Still using the archive or escalation or other mechanism may be the best answer for your specific situation. I just wanted to explain the reason that you were having the issue with the qualifier below. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 6:49 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Application-Query-Delete-Entry
Dave, All the other suggestions about archive and escalations and the like apply as different ways to get this done. But, to tell you why what you were doing below doesn’t work and to help any other users having issues with qualifiers in run processes. Use $\TIMESTAMP$ instead of $TIMESTAMP$ in the qualifier. The extra \ is to escape interpretation of the value. As entered, the TIMESTAMP keyword is expanded as it is processing rather than being a keyword so you get the syntax error. Putting in the \ will keep it a keyword and your qualifier should do what you wanted. This syntax is needed only for situations where you are putting a qualifier inside the logic of an operation (not in the RunIF but in places where normally the keyword is expanded during as the operation proceeds). (and I think it is a \. If not, try /…..) NOTE: Still using the archive or escalation or other mechanism may be the best answer for your specific situation. I just wanted to explain the reason that you were having the issue with the qualifier below. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 6:49 AM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _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"
Re: EXTERNAL: Application-Query-Delete-Entry
Sort of like Todd says, I had a similar situation but with a much larger form in 6.3 using archive, delete from source. What I did was a little bit each night changing the archive query each morning sort of like this ‘Create Date’ < $DATE$ - (60 * 60 *24 * 720) ‘Create Date’ < $DATE$ - (60 * 60 *24 * 713) ‘Create Date’ < $DATE$ - (60 * 60 *24 * 706) Took me about a month to get where I wanted to be. Slow but if you’re worried about performance, that works Mark From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Wednesday, August 31, 2016 2:55 AM To: arslist@ARSLIST.ORG Subject: Re: EXTERNAL: Application-Query-Delete-Entry ** Todd, Regardless of the method used (archiving, or application-query-delete-entry), I realised this could be a problem - I've already (manually) cleared down the email messages form. Awkward though, as I had set it to run overnight and delete a small data set (should have only been 21 records), and it doesn't appear to have done anything. Regards Dave On 30 August 2016 at 16:39, Arner, Todd <tar...@glhec.org<mailto:tar...@glhec.org>> wrote: ** Be cautious when adding the archiving, especially if the first night it runs if it will be trying to archive a large number of records. We ran into some major performance issues. We ended up slow adjusting the archive criteria so that a smaller amount of records were archived each night until the back log was processed. Todd Arner Great Lakes From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 10:29 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: EXTERNAL: Application-Query-Delete-Entry ** I had completely forgotten about the archiving options (my bad, etc. etc) Much appreciated, I've put that in place to run overnight, with luck it should work! On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com<mailto:john.j.rei...@lmco.com>> wrote: ** Dave, Have you tried using the Archive function to just “Delete from Source”? It sets up just like an escalation with a timing cycle to run it and a Qualification to select which data to delete. Thank you, --- John J. Reiser Building 760-J202 Remedy AR System Developer Senior Software Development Analyst Lockheed Martin - MST Moorestown Region The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 9:49 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: EXTERNAL: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _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_ The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be protected under state or federal law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please forward the communication to no...@glhec.org<mailto:no...@glhec.org> immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are&
Re: EXTERNAL: Application-Query-Delete-Entry
Todd, Regardless of the method used (archiving, or application-query-delete-entry), I realised this could be a problem - I've already (manually) cleared down the email messages form. Awkward though, as I had set it to run overnight and delete a small data set (should have only been 21 records), and it doesn't appear to have done anything. Regards Dave On 30 August 2016 at 16:39, Arner, Todd <tar...@glhec.org> wrote: > ** > > Be cautious when adding the archiving, especially if the first night it > runs if it will be trying to archive a large number of records. We ran > into some major performance issues. We ended up slow adjusting the archive > criteria so that a smaller amount of records were archived each night until > the back log was processed. > > > > Todd Arner > > Great Lakes > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 10:29 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: EXTERNAL: Application-Query-Delete-Entry > > > > ** > > I had completely forgotten about the archiving options (my bad, etc. etc) > > Much appreciated, I've put that in place to run overnight, with luck it > should work! > > > > On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com> wrote: > > ** > > Dave, > > Have you tried using the Archive function to just “Delete from Source”? > > It sets up just like an escalation with a timing cycle to run it and a > Qualification to select which data to delete. > > > > Thank you, > > --- > John J. Reiser > Building 760-J202 > Remedy AR System Developer > > Senior Software Development Analyst > Lockheed Martin - MST Moorestown Region > The star that burns twice as bright burns half as long. > Pay close attention and be illuminated by its brilliance. - paraphrased by > me > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 9:49 AM > *To:* arslist@ARSLIST.ORG > *Subject:* EXTERNAL: Application-Query-Delete-Entry > > > > ** > > All, > > I'm trying to figure out the syntax required for > Application-Query-Delete-Entry (Server is running ARS 7.5) > > Trying to keep an "archive" of emails - we have a requirement to keep 6 > months worth in the system (audit trail, proof of sending, etc.), and the > form was actually turning out to be the largest on the system (over 7 > million records - I manually deleted the older ones via the user tool, that > is not fun!). > > In an active link, just trying a simple > > $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" > '3' < ($TIMESTAMP$ - (86400 * 75)) > > The 75 is related to a test system and the data that is on it (would > obviously be changed on live). The query itself is fine against the email > messages form, it just comes up with a qualification error when run via the > active link. > > Any suggestions? I could try an alternative using > Application-Delete-Entry and table walking, but that'll > be horrendously inefficient in comparison to Application-Query-Delete- > Entry. > > Regards > > Dave Barber > > _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_ > -- > The information contained in this communication may be confidential, is > intended only for the use of the recipient(s) named above, and may be > protected under state or federal law. If the reader of this message is not > the intended recipient, you are hereby notified that any dissemination, > distribution, or copying of this communication, or any of its contents, is > strictly prohibited. If you have received this communication in error, > please forward the communication to no...@glhec.org immediately and > destroy or delete the original message and any copy of it from your > computer system. If you have any questions concerning this message, please > contact the sender. > _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"
Re: EXTERNAL: Application-Query-Delete-Entry
Using the RRR|Chive method I started to delete 2.5 million (2,449,811 to be exact) Email Messages one evening and it was finished the next morning when I returned. I just looked the run time from the logs. It took 7.5 hours. It put some extra (CPU) load on the system but I didn't notice any performance decrease in the UI. If you need you can specific a nicepausetime setting to lessen the load. Jason On Tue, Aug 30, 2016 at 9:04 AM, Reiser, John J <john.j.rei...@lmco.com> wrote: > ** > > Agreed. I set mine up with ‘Create Date’ < $DATE$ - (86400 * 365 * 5) > since I only had 5 years of back log. Someone thought saving every email > was a good idea. > > Then each week I lowered the multiplier by 0.1 so now I’m down to (86400 * > 365 * 2.9). > > We had 2.6 million email. > > > > Thank you, > > --- > John J. Reiser > Building 760-J202 > Remedy AR System Developer > > Senior Software Development Analyst > Lockheed Martin - MST Moorestown Region > The star that burns twice as bright burns half as long. > Pay close attention and be illuminated by its brilliance. - paraphrased by > me > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Arner, Todd > *Sent:* Tuesday, August 30, 2016 11:39 AM > > *To:* arslist@ARSLIST.ORG > *Subject:* Re: EXTERNAL: Application-Query-Delete-Entry > > > > ** > > Be cautious when adding the archiving, especially if the first night it > runs if it will be trying to archive a large number of records. We ran > into some major performance issues. We ended up slow adjusting the archive > criteria so that a smaller amount of records were archived each night until > the back log was processed. > > > > Todd Arner > > Great Lakes > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *Dave > Barber > *Sent:* Tuesday, August 30, 2016 10:29 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: EXTERNAL: Application-Query-Delete-Entry > > > > ** > > I had completely forgotten about the archiving options (my bad, etc. etc) > > Much appreciated, I've put that in place to run overnight, with luck it > should work! > > > > On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com> wrote: > > ** > > Dave, > > Have you tried using the Archive function to just “Delete from Source”? > > It sets up just like an escalation with a timing cycle to run it and a > Qualification to select which data to delete. > > > > Thank you, > > --- > John J. Reiser > Building 760-J202 > Remedy AR System Developer > > Senior Software Development Analyst > Lockheed Martin - MST Moorestown Region > The star that burns twice as bright burns half as long. > Pay close attention and be illuminated by its brilliance. - paraphrased by > me > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 9:49 AM > *To:* arslist@ARSLIST.ORG > *Subject:* EXTERNAL: Application-Query-Delete-Entry > > > > ** > > All, > > I'm trying to figure out the syntax required for > Application-Query-Delete-Entry (Server is running ARS 7.5) > > Trying to keep an "archive" of emails - we have a requirement to keep 6 > months worth in the system (audit trail, proof of sending, etc.), and the > form was actually turning out to be the largest on the system (over 7 > million records - I manually deleted the older ones via the user tool, that > is not fun!). > > In an active link, just trying a simple > > $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" > '3' < ($TIMESTAMP$ - (86400 * 75)) > > The 75 is related to a test system and the data that is on it (would > obviously be changed on live). The query itself is fine against the email > messages form, it just comes up with a qualification error when run via the > active link. > > Any suggestions? I could try an alternative using > Application-Delete-Entry and table walking, but that'll > be horrendously inefficient in comparison to Application-Query-Delete- > Entry. > > Regards > > Dave Barber > > _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_ > -- > > The information contained in this communication may be confidential, is > intended only for the
Re: EXTERNAL: Application-Query-Delete-Entry
Agreed. I set mine up with ‘Create Date’ < $DATE$ - (86400 * 365 * 5) since I only had 5 years of back log. Someone thought saving every email was a good idea. Then each week I lowered the multiplier by 0.1 so now I’m down to (86400 * 365 * 2.9). We had 2.6 million email. Thank you, --- John J. Reiser Building 760-J202 Remedy AR System Developer Senior Software Development Analyst Lockheed Martin - MST Moorestown Region The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Arner, Todd Sent: Tuesday, August 30, 2016 11:39 AM To: arslist@ARSLIST.ORG Subject: Re: EXTERNAL: Application-Query-Delete-Entry ** Be cautious when adding the archiving, especially if the first night it runs if it will be trying to archive a large number of records. We ran into some major performance issues. We ended up slow adjusting the archive criteria so that a smaller amount of records were archived each night until the back log was processed. Todd Arner Great Lakes From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 10:29 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: EXTERNAL: Application-Query-Delete-Entry ** I had completely forgotten about the archiving options (my bad, etc. etc) Much appreciated, I've put that in place to run overnight, with luck it should work! On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com<mailto:john.j.rei...@lmco.com>> wrote: ** Dave, Have you tried using the Archive function to just “Delete from Source”? It sets up just like an escalation with a timing cycle to run it and a Qualification to select which data to delete. Thank you, --- John J. Reiser Building 760-J202 Remedy AR System Developer Senior Software Development Analyst Lockheed Martin - MST Moorestown Region The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 9:49 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: EXTERNAL: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _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_ The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be protected under state or federal law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please forward the communication to no...@glhec.org<mailto:no...@glhec.org> immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. _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"
Re: EXTERNAL: Application-Query-Delete-Entry
Be cautious when adding the archiving, especially if the first night it runs if it will be trying to archive a large number of records. We ran into some major performance issues. We ended up slow adjusting the archive criteria so that a smaller amount of records were archived each night until the back log was processed. Todd Arner Great Lakes From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 10:29 AM To: arslist@ARSLIST.ORG Subject: Re: EXTERNAL: Application-Query-Delete-Entry ** I had completely forgotten about the archiving options (my bad, etc. etc) Much appreciated, I've put that in place to run overnight, with luck it should work! On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com<mailto:john.j.rei...@lmco.com>> wrote: ** Dave, Have you tried using the Archive function to just “Delete from Source”? It sets up just like an escalation with a timing cycle to run it and a Qualification to select which data to delete. Thank you, --- John J. Reiser Building 760-J202 Remedy AR System Developer Senior Software Development Analyst Lockheed Martin - MST Moorestown Region The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 9:49 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: EXTERNAL: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _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_ -- The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be protected under state or federal law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please forward the communication to no...@glhec.org immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: EXTERNAL: Application-Query-Delete-Entry
I had completely forgotten about the archiving options (my bad, etc. etc) Much appreciated, I've put that in place to run overnight, with luck it should work! On 30 August 2016 at 15:11, Reiser, John J <john.j.rei...@lmco.com> wrote: > ** > > Dave, > > Have you tried using the Archive function to just “Delete from Source”? > > It sets up just like an escalation with a timing cycle to run it and a > Qualification to select which data to delete. > > > > Thank you, > > --- > John J. Reiser > Building 760-J202 > Remedy AR System Developer > > Senior Software Development Analyst > Lockheed Martin - MST Moorestown Region > The star that burns twice as bright burns half as long. > Pay close attention and be illuminated by its brilliance. - paraphrased by > me > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 9:49 AM > *To:* arslist@ARSLIST.ORG > *Subject:* EXTERNAL: Application-Query-Delete-Entry > > > > ** > > All, > > I'm trying to figure out the syntax required for > Application-Query-Delete-Entry (Server is running ARS 7.5) > > Trying to keep an "archive" of emails - we have a requirement to keep 6 > months worth in the system (audit trail, proof of sending, etc.), and the > form was actually turning out to be the largest on the system (over 7 > million records - I manually deleted the older ones via the user tool, that > is not fun!). > > In an active link, just trying a simple > > $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" > '3' < ($TIMESTAMP$ - (86400 * 75)) > > The 75 is related to a test system and the data that is on it (would > obviously be changed on live). The query itself is fine against the email > messages form, it just comes up with a qualification error when run via the > active link. > > Any suggestions? I could try an alternative using > Application-Delete-Entry and table walking, but that'll > be horrendously inefficient in comparison to Application-Query-Delete- > Entry. > > Regards > > Dave Barber > > _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"
Re: Application-Query-Delete-Entry
Here is an example I found on our server.
Active Link: AR System Email Template Association Delete on the AR System
Email Templates form.
@@:Application-Query-Delete-Entry "AR System Email Association" ( '18001' =
"Template") AND ( '18134' = "$Unique Identifier$") AND ( '18000' =
"$Attachment GUID Column$")
Here is another one
Active Link: LDAP AREA:DeleteConf0
IF:
@@:Application-Query-Delete-Entry "Configuration ARDBC" '536870913' LIKE
"AREA-LDAP-%_$ColumnOrder$"
ELSE:
@@:Application-Query-Delete-Entry "Configuration ARDBC" ('536870913' LIKE
"AREA-LDAP-%") AND (NOT('536870913' LIKE "AREA-LDAP-%[_]%"))
Are you doing this in a Run Process action or a Set Fields action using
$PROCESS$ ? If you are doing it in a Run Process then try removing
$PROCESS$
Jason
On Tue, Aug 30, 2016 at 8:07 AM Jason Miller <jason.mil...@gmail.com> wrote:
> Hi Dave,
>
> This is a bit tangent to Application-Query-Delete-Entry but related to
> deleting AR System Email Messages (we were recently at 3 mil). We use to do
> exactly the same thing; run a query in User Tool --> Delete. Now we use
> RRR|Chive to delete. It is nice and gentle on both the AR Server and the PC
> it is being run from and does it all in one shot based on a query.
>
> Check the details on the BMC Communities:
> https://communities.bmc.com/message/615453
>
> Jason
>
> On Tue, Aug 30, 2016 at 7:12 AM CRENSHAW, CRYSTAL <
> crystal.crens...@ncsecu.org> wrote:
>
>> **
>>
>> Dave,
>>
>>
>>
>> We have created an escalation for version 8.1.01.
>>
>>
>>
>> The Run If is *'Modified Date' < ($DATE$ - (10 * 86400))* <> keep 10 days<<
>>
>>
>>
>>
>>
>> And the Run Process is: *Application-Delete-Entry "$SCHEMA$" $Email ID$*
>>
>>
>>
>>
>>
>> Not sure if that will work for your version but hope that helps.
>>
>>
>>
>> Thanks,
>>
>>
>>
>>
>>
>> Crystal Crenshaw
>>
>> Service Management Senior Systems Analyst
>>
>> Project Services – Service Management
>>
>> (919)508-0546
>>
>>
>>
>>
>>
>> *From:* Action Request System discussion list(ARSList) [mailto:
>> arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber
>> *Sent:* Tuesday, August 30, 2016 9:49 AM
>> *To:* arslist@ARSLIST.ORG
>> *Subject:* Application-Query-Delete-Entry
>>
>>
>>
>> **
>>
>> All,
>>
>> I'm trying to figure out the syntax required for
>> Application-Query-Delete-Entry (Server is running ARS 7.5)
>>
>> Trying to keep an "archive" of emails - we have a requirement to keep 6
>> months worth in the system (audit trail, proof of sending, etc.), and the
>> form was actually turning out to be the largest on the system (over 7
>> million records - I manually deleted the older ones via the user tool, that
>> is not fun!).
>>
>> In an active link, just trying a simple
>>
>> $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages"
>> '3' < ($TIMESTAMP$ - (86400 * 75))
>>
>> The 75 is related to a test system and the data that is on it (would
>> obviously be changed on live). The query itself is fine against the email
>> messages form, it just comes up with a qualification error when run via the
>> active link.
>>
>> Any suggestions? I could try an alternative using
>> Application-Delete-Entry and table walking, but that'll
>> be horrendously inefficient in comparison to Application-Query-Delete-Entry.
>>
>> Regards
>>
>> Dave Barber
>>
>> _ARSlist: "Where the Answers Are" and have been for 20 years_
>>
>> This email may contain confidential and privileged material for the sole
>> use of the intended recipient. If you are not the intended recipient,
>> please contact the sender and delete all copies. Any review or distribution
>> by others is strictly prohibited. Personal emails are restricted by policy
>> of the State Employees' Credit Union (SECU). Therefore SECU specifically
>> disclaims any responsibility or liability for any personal information or
>> opinions of the author expressed in this email.
>>
>> _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"
Re: Application-Query-Delete-Entry
Hi Dave, This is a bit tangent to Application-Query-Delete-Entry but related to deleting AR System Email Messages (we were recently at 3 mil). We use to do exactly the same thing; run a query in User Tool --> Delete. Now we use RRR|Chive to delete. It is nice and gentle on both the AR Server and the PC it is being run from and does it all in one shot based on a query. Check the details on the BMC Communities: https://communities.bmc.com/message/615453 Jason On Tue, Aug 30, 2016 at 7:12 AM CRENSHAW, CRYSTAL < crystal.crens...@ncsecu.org> wrote: > ** > > Dave, > > > > We have created an escalation for version 8.1.01. > > > > The Run If is *'Modified Date' < ($DATE$ - (10 * 86400))* < keep 10 days<< > > > > > > And the Run Process is: *Application-Delete-Entry "$SCHEMA$" $Email ID$* > > > > > > Not sure if that will work for your version but hope that helps. > > > > Thanks, > > > > > > Crystal Crenshaw > > Service Management Senior Systems Analyst > > Project Services – Service Management > > (919)508-0546 > > > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Dave Barber > *Sent:* Tuesday, August 30, 2016 9:49 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Application-Query-Delete-Entry > > > > ** > > All, > > I'm trying to figure out the syntax required for > Application-Query-Delete-Entry (Server is running ARS 7.5) > > Trying to keep an "archive" of emails - we have a requirement to keep 6 > months worth in the system (audit trail, proof of sending, etc.), and the > form was actually turning out to be the largest on the system (over 7 > million records - I manually deleted the older ones via the user tool, that > is not fun!). > > In an active link, just trying a simple > > $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" > '3' < ($TIMESTAMP$ - (86400 * 75)) > > The 75 is related to a test system and the data that is on it (would > obviously be changed on live). The query itself is fine against the email > messages form, it just comes up with a qualification error when run via the > active link. > > Any suggestions? I could try an alternative using > Application-Delete-Entry and table walking, but that'll > be horrendously inefficient in comparison to Application-Query-Delete-Entry. > > Regards > > Dave Barber > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > This email may contain confidential and privileged material for the sole > use of the intended recipient. If you are not the intended recipient, > please contact the sender and delete all copies. Any review or distribution > by others is strictly prohibited. Personal emails are restricted by policy > of the State Employees' Credit Union (SECU). Therefore SECU specifically > disclaims any responsibility or liability for any personal information or > opinions of the author expressed in this email. > > _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"
Re: Application-Query-Delete-Entry
Usually I have to enclose Date values in strings
And I enclose the entire query string in a set of parenthesis
('3' < (“$TIMESTAMP$” - (86400 * 75)))
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber
Sent: Tuesday, August 30, 2016 8:49 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
All,
I'm trying to figure out the syntax required for Application-Query-Delete-Entry
(Server is running ARS 7.5)
Trying to keep an "archive" of emails - we have a requirement to keep 6 months
worth in the system (audit trail, proof of sending, etc.), and the form was
actually turning out to be the largest on the system (over 7 million records -
I manually deleted the older ones via the user tool, that is not fun!).
In an active link, just trying a simple
$PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' <
($TIMESTAMP$ - (86400 * 75))
The 75 is related to a test system and the data that is on it (would obviously
be changed on live). The query itself is fine against the email messages form,
it just comes up with a qualification error when run via the active link.
Any suggestions? I could try an alternative using Application-Delete-Entry
and table walking, but that'll be horrendously inefficient
in comparison to Application-Query-Delete-Entry.
Regards
Dave Barber
_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"
Re: Application-Query-Delete-Entry
Dave, what would you think of an escalation that fires using the same qualification and does an Application-Delete-Entry "$SCHEMA$" $1$, have it fire daily if you care to and it'll automatically keep the records trimmed. On Tue, Aug 30, 2016 at 7:48 AM, Dave Barber <daddy.bar...@gmail.com> wrote: > ** > All, > > I'm trying to figure out the syntax required for > Application-Query-Delete-Entry (Server is running ARS 7.5) > > Trying to keep an "archive" of emails - we have a requirement to keep 6 > months worth in the system (audit trail, proof of sending, etc.), and the > form was actually turning out to be the largest on the system (over 7 > million records - I manually deleted the older ones via the user tool, that > is not fun!). > > In an active link, just trying a simple > $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" > '3' < ($TIMESTAMP$ - (86400 * 75)) > > The 75 is related to a test system and the data that is on it (would > obviously be changed on live). The query itself is fine against the email > messages form, it just comes up with a qualification error when run via the > active link. > > Any suggestions? I could try an alternative using > Application-Delete-Entry and table walking, but that'll > be horrendously inefficient in comparison to Application-Query-Delete- > Entry. > > Regards > > Dave Barber > _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"
Re: EXTERNAL: Application-Query-Delete-Entry
Dave, Have you tried using the Archive function to just “Delete from Source”? It sets up just like an escalation with a timing cycle to run it and a Qualification to select which data to delete. Thank you, --- John J. Reiser Building 760-J202 Remedy AR System Developer Senior Software Development Analyst Lockheed Martin - MST Moorestown Region The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 9:49 AM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _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"
Re: Application-Query-Delete-Entry
Dave, We have created an escalation for version 8.1.01. The Run If is 'Modified Date' < ($DATE$ - (10 * 86400)) <mailto:arslist@ARSLIST.ORG] On Behalf Of Dave Barber Sent: Tuesday, August 30, 2016 9:49 AM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry ** All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber _ARSlist: "Where the Answers Are" and have been for 20 years_ This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Application-Query-Delete-Entry
All, I'm trying to figure out the syntax required for Application-Query-Delete-Entry (Server is running ARS 7.5) Trying to keep an "archive" of emails - we have a requirement to keep 6 months worth in the system (audit trail, proof of sending, etc.), and the form was actually turning out to be the largest on the system (over 7 million records - I manually deleted the older ones via the user tool, that is not fun!). In an active link, just trying a simple $PROCESS$ @@:Application-Query-Delete-Entry "AR System Email Messages" '3' < ($TIMESTAMP$ - (86400 * 75)) The 75 is related to a test system and the data that is on it (would obviously be changed on live). The query itself is fine against the email messages form, it just comes up with a qualification error when run via the active link. Any suggestions? I could try an alternative using Application-Delete-Entry and table walking, but that'll be horrendously inefficient in comparison to Application-Query-Delete-Entry. Regards Dave Barber ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Application-Query-Delete-Entry
Hi, I did my PTT (Performance Tuning Troubleshooting class) in 1998, and had an argument with the teacher. I produced some log files to prove my case during class, but she refused to accept that as proof, and I gave up ;-) Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasn’t told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Hi, Filters triggered by an Escalation, either via Set-Fields or Push-Fields, will ALWAYS be run in the same thread. This has ALWAYS been the case. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. Now that you remind me, I actually remember discussing this once with you.. I'll really need to log the workflow to see what thread processes the filter workflow when filters are executed triggered by the AR_ESCALATOR user. I was told this in a performance tuning class years ago (version 4.0 - 4.5 days so probably 11 or 12 years ago) that you let escalations perform first stage actions, and leave any 2nd and 3rd stage actions (deletes, push fields, notifications) to be performed by filters that are run using the admin thread. Maybe the design was different back then? So this is obsolete now? I wish I had a server to verify this :-) Joe -Original Message- From: LJ LongWing Sent: Thursday, December 08, 2011 2:18 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut you and I seem to differ in our opinions of how it works. So...based on your statement below, having the escalation set a field, and having a filter fire on that field being set, then performing the delete will be 'faster' because of a 'fire and forget' type of mechanism? I would argue that an action of delete within the escalation, and a setfield causing a filter to fire that causes the delete are 'the same', in that the escalation thread does not 'go onto the next record' till after the filters on the current record are done...so, in essence, the performance of either action would be the same and the escalation thread would still be tied up for exactly the same amount of time regardless At least, that's my understanding :) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 11:33 AM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry End Date as Linda pointed out should be a field on that form you are searching for, represented by 'End Date' in the qualification and not $End Date$.. That being said, LJ's suggestion is right.. The qualification should be in the Run If of the Escalation and the run process should be Application-Delete-Entry $SCHEMA$ $Request ID$ Having an Escalation with no Run If instructs it to be run over the entire data table. You do not want to do that in case you have like a million or more records in it.. It may probably hang the escalation thread waiting for it to complete.. Also a faster way to do it would be to 'mark that entry for deletion' using a tag on a field created for that. This would mean that the Escalation would do a single update to that table which is a faster operation that multiple deletes and be done with it.. Create a filter that runs if the $USER$ is AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a fairly large set of data, although the deletes
Re: Application-Query-Delete-Entry
I doubt too many instructors would be taking you on in argument about Remedy these days Misi. They'd have to be game!! One thing I'd like to add is that all other things being equal I think the query version of delete entry should be a fair bit faster for bulk deletes. I think if you do have a bunch of records tagged to delete that the first match could delete all the other ones in the one go. I doubt this would be as fast as a database level delete as you still have the app server overhead and the potential to run Delete filters on each delete but I think it would be faster than doing a modify and delete on each match. I still prefer the control that putting all the logic in the one place - filters gives. If you use escalations for just identifying data that needs attention then it makes it easier to develop accurate maintainable bug free code. Rod Harris On 12 December 2011 16:23, Misi Mladoniczky m...@rrr.se wrote: Hi, I did my PTT (Performance Tuning Troubleshooting class) in 1998, and had an argument with the teacher. I produced some log files to prove my case during class, but she refused to accept that as proof, and I gave up ;-) Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasn’t told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Hi, Filters triggered by an Escalation, either via Set-Fields or Push-Fields, will ALWAYS be run in the same thread. This has ALWAYS been the case. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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 . Now that you remind me, I actually remember discussing this once with you.. I'll really need to log the workflow to see what thread processes the filter workflow when filters are executed triggered by the AR_ESCALATOR user. I was told this in a performance tuning class years ago (version 4.0 - 4.5 days so probably 11 or 12 years ago) that you let escalations perform first stage actions, and leave any 2nd and 3rd stage actions (deletes, push fields, notifications) to be performed by filters that are run using the admin thread. Maybe the design was different back then? So this is obsolete now? I wish I had a server to verify this :-) Joe -Original Message- From: LJ LongWing Sent: Thursday, December 08, 2011 2:18 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut you and I seem to differ in our opinions of how it works. So...based on your statement below, having the escalation set a field, and having a filter fire on that field being set, then performing the delete will be 'faster' because of a 'fire and forget' type of mechanism? I would argue that an action of delete within the escalation, and a setfield causing a filter to fire that causes the delete are 'the same', in that the escalation thread does not 'go onto the next record' till after the filters on the current record are done...so, in essence, the performance of either action would be the same and the escalation thread would still be tied up for exactly the same amount of time regardless At least, that's my understanding :) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 11:33 AM To: arslist@ARSLIST.ORG Subject: Re: Application
Re: Application-Query-Delete-Entry
Hi, I have doe quite some testing with deleting entries. The problem with Application-Query-Delete-Entry is that it is treated as ONE database transaction. That means that the database needs to be able to roll back the delet, and copies everything to a transaction-space or something like that. This all makes it choke, if it is too many records. Even deleting 100 records at a time may be a problem if you have big attachments. I suggest that you use Application-Delete-Entry directly from your escalation. If you want to delete child records, create a filter executing on Delete, that calls Application-Query-Delete-Entry. This is the place where I have found that function useful. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. I doubt too many instructors would be taking you on in argument about Remedy these days Misi. They'd have to be game!! One thing I'd like to add is that all other things being equal I think the query version of delete entry should be a fair bit faster for bulk deletes. I think if you do have a bunch of records tagged to delete that the first match could delete all the other ones in the one go. I doubt this would be as fast as a database level delete as you still have the app server overhead and the potential to run Delete filters on each delete but I think it would be faster than doing a modify and delete on each match. I still prefer the control that putting all the logic in the one place - filters gives. If you use escalations for just identifying data that needs attention then it makes it easier to develop accurate maintainable bug free code. Rod Harris On 12 December 2011 16:23, Misi Mladoniczky m...@rrr.se wrote: Hi, I did my PTT (Performance Tuning Troubleshooting class) in 1998, and had an argument with the teacher. I produced some log files to prove my case during class, but she refused to accept that as proof, and I gave up ;-) Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasn’t told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Hi, Filters triggered by an Escalation, either via Set-Fields or Push-Fields, will ALWAYS be run in the same thread. This has ALWAYS been the case. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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 . Now that you remind me, I actually remember discussing this once with you.. I'll really need to log the workflow to see what thread processes the filter workflow when filters are executed triggered by the AR_ESCALATOR user. I was told this in a performance tuning class years ago (version 4.0 - 4.5 days so probably 11 or 12 years ago) that you let escalations perform first stage actions, and leave any 2nd and 3rd stage actions (deletes, push fields, notifications) to be performed by filters that are run using the admin thread. Maybe the design was different back then? So this is obsolete now? I wish I had a server to verify this :-) Joe -Original Message- From: LJ LongWing Sent: Thursday, December 08, 2011 2:18 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know
Re: Application-Query-Delete-Entry
Thanks Misi, you are a founatin of knowledge and I guess that makes sense. It would be one database transaction and everything would need to be rolled back if it failed. I've used it to delete several hundred temporary rows at a time no problem and it is faster than running several hundred updates. I think if, as you say, you need to update maybe thousands of rows it might become a bit impractical. Might be safer in most instances to go the scalable approach and use the individual delete entry. Of course there are times when it is best to do all the deletes as one transaction as in my situation where a bunch of temporary rows were created and then deleted soon after. Makes sense not to leave any mess behind if there is a problem and by skipping the modify actions you're saving a bit of time and reducing the risk of some unintended cascading modify. (I've seen a bug caused by this in a recent version of well known Remedy app). Most of the time the individual delete is probably the right way to go and have it tiggered by a simple escalation and (whilst still using one thread) split each delete into a separate transaction. Each deleted row should have a delete filter to delete children. Would you then think deleting children by a query delete or push fields update would be the way to go? Either way the delete children would be combined into one transaction. Rod Harris On 12 December 2011 21:42, Misi Mladoniczky m...@rrr.se wrote: Hi, I have doe quite some testing with deleting entries. The problem with Application-Query-Delete-Entry is that it is treated as ONE database transaction. That means that the database needs to be able to roll back the delet, and copies everything to a transaction-space or something like that. This all makes it choke, if it is too many records. Even deleting 100 records at a time may be a problem if you have big attachments. I suggest that you use Application-Delete-Entry directly from your escalation. If you want to delete child records, create a filter executing on Delete, that calls Application-Query-Delete-Entry. This is the place where I have found that function useful. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. I doubt too many instructors would be taking you on in argument about Remedy these days Misi. They'd have to be game!! One thing I'd like to add is that all other things being equal I think the query version of delete entry should be a fair bit faster for bulk deletes. I think if you do have a bunch of records tagged to delete that the first match could delete all the other ones in the one go. I doubt this would be as fast as a database level delete as you still have the app server overhead and the potential to run Delete filters on each delete but I think it would be faster than doing a modify and delete on each match. I still prefer the control that putting all the logic in the one place - filters gives. If you use escalations for just identifying data that needs attention then it makes it easier to develop accurate maintainable bug free code. Rod Harris On 12 December 2011 16:23, Misi Mladoniczky m...@rrr.se wrote: Hi, I did my PTT (Performance Tuning Troubleshooting class) in 1998, and had an argument with the teacher. I produced some log files to prove my case during class, but she refused to accept that as proof, and I gave up ;-) Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasn’t told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups
Re: Application-Query-Delete-Entry
Hi, If your children is to be deletet, I think that a Application-Query-Delete-Entry call would be the cleanest way to go. If the child does not want to be deleted, it can send an Error. If you do a push, the database will be updated, and the modify-filters will run, which seems unnecessary. If you do it in two steps (with an additional child-form-escalation), the delete will not be contained within one transaction. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. Thanks Misi, you are a founatin of knowledge and I guess that makes sense. It would be one database transaction and everything would need to be rolled back if it failed. I've used it to delete several hundred temporary rows at a time no problem and it is faster than running several hundred updates. I think if, as you say, you need to update maybe thousands of rows it might become a bit impractical. Might be safer in most instances to go the scalable approach and use the individual delete entry. Of course there are times when it is best to do all the deletes as one transaction as in my situation where a bunch of temporary rows were created and then deleted soon after. Makes sense not to leave any mess behind if there is a problem and by skipping the modify actions you're saving a bit of time and reducing the risk of some unintended cascading modify. (I've seen a bug caused by this in a recent version of well known Remedy app). Most of the time the individual delete is probably the right way to go and have it tiggered by a simple escalation and (whilst still using one thread) split each delete into a separate transaction. Each deleted row should have a delete filter to delete children. Would you then think deleting children by a query delete or push fields update would be the way to go? Either way the delete children would be combined into one transaction. Rod Harris On 12 December 2011 21:42, Misi Mladoniczky m...@rrr.se wrote: Hi, I have doe quite some testing with deleting entries. The problem with Application-Query-Delete-Entry is that it is treated as ONE database transaction. That means that the database needs to be able to roll back the delet, and copies everything to a transaction-space or something like that. This all makes it choke, if it is too many records. Even deleting 100 records at a time may be a problem if you have big attachments. I suggest that you use Application-Delete-Entry directly from your escalation. If you want to delete child records, create a filter executing on Delete, that calls Application-Query-Delete-Entry. This is the place where I have found that function useful. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. I doubt too many instructors would be taking you on in argument about Remedy these days Misi. They'd have to be game!! One thing I'd like to add is that all other things being equal I think the query version of delete entry should be a fair bit faster for bulk deletes. I think if you do have a bunch of records tagged to delete that the first match could delete all the other ones in the one go. I doubt this would be as fast as a database level delete as you still have the app server overhead and the potential to run Delete filters on each delete but I think it would be faster than doing a modify and delete on each match. I still prefer the control that putting all the logic in the one place - filters gives. If you use escalations for just identifying data that needs attention then it makes it easier to develop accurate maintainable bug free code. Rod Harris On 12 December 2011 16:23, Misi Mladoniczky m...@rrr.se wrote: Hi, I did my PTT (Performance Tuning Troubleshooting class) in 1998, and had an argument with the teacher. I produced some log files to prove my case during class, but she refused to accept that as proof, and I gave up ;-) Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. That shatters a long standing understanding I had about
Re: Application-Query-Delete-Entry
Hi,
Filters triggered by an Escalation, either via Set-Fields or Push-Fields,
will ALWAYS be run in the same thread.
This has ALWAYS been the case.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* 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.
Now that you remind me, I actually remember discussing this once with
you..
I'll really need to log the workflow to see what thread processes the
filter
workflow when filters are executed triggered by the AR_ESCALATOR user.
I was told this in a performance tuning class years ago (version 4.0 - 4.5
days so probably 11 or 12 years ago) that you let escalations perform
first
stage actions, and leave any 2nd and 3rd stage actions (deletes, push
fields, notifications) to be performed by filters that are run using the
admin thread. Maybe the design was different back then? So this is
obsolete
now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a
setfield
causing a filter to fire that causes the delete are 'the same', in that
the
escalation thread does not 'go onto the next record' till after the
filters
on the current record are done...so, in essence, the performance of either
action would be the same and the escalation thread would still be tied up
for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting
for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion'
using
a tag on a field created for that. This would mean that the Escalation
would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that
matches
your qualification, and then performs your action on ALL records that
match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply
perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date
is
more than 6 months prior to todays date. I built the escalation and when
I
run it nothing happens. Can someone point in the right directions with
the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM
Re: Application-Query-Delete-Entry
That shatters a long standing understanding I had about data driven
escalations. I had received this info at a Remedy training facility in
Bracknell in UK years ago, that you ought to help Escalations with Filters
triggered off modifications by the Escalation User in processing 2nd and 3rd
stage actions. I guess they were wrong when they instructed us so then..
That is one of the benefit that they explained of having Filters running
with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the
qualification may be.. The other benefit I'm guessing (I wasn’t told this
but it makes sense) is if you need to override filter phasing during the run
of an escalation..
Joe
-Original Message-
From: Misi Mladoniczky
Sent: Saturday, December 10, 2011 4:04 AM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Hi,
Filters triggered by an Escalation, either via Set-Fields or Push-Fields,
will ALWAYS be run in the same thread.
This has ALWAYS been the case.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* 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.
Now that you remind me, I actually remember discussing this once with
you..
I'll really need to log the workflow to see what thread processes the
filter
workflow when filters are executed triggered by the AR_ESCALATOR user.
I was told this in a performance tuning class years ago (version 4.0 - 4.5
days so probably 11 or 12 years ago) that you let escalations perform
first
stage actions, and leave any 2nd and 3rd stage actions (deletes, push
fields, notifications) to be performed by filters that are run using the
admin thread. Maybe the design was different back then? So this is
obsolete
now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a
setfield
causing a filter to fire that causes the delete are 'the same', in that
the
escalation thread does not 'go onto the next record' till after the
filters
on the current record are done...so, in essence, the performance of either
action would be the same and the escalation thread would still be tied up
for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting
for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion'
using
a tag on a field created for that. This would mean that the Escalation
would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that
matches
your qualification, and then performs your action on ALL records that
match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180
Re: Application-Query-Delete-Entry
From the Filter log (and this is even from Application-Query-Delete-Entry action) FLTR TID: 4027734928 RPC ID: 001637 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) /* Sat Dec 10 2011 13:27:52.0979 */ Start filter processing (phase 1) -- Operation - DELETE on MyFormName - 5840476 As you can see the filters fire using the Escalation thread. Application-Query-Delete-Entry is a benefit when deleting child form records. Take the example of the order with line items. Instead of pushing a value to each line item for the order, you execute the Application-Query-Delete-Entry in the delete of the order record to delete the child line items. The main reason for using a field to trigger a delete (using a Filter) for me, is I can then manually trigger the same Filters at any time I need to. It makes testing my workflow so much easier than waiting for an Escalation and searching thru the logs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Saturday, December 10, 2011 12:59 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasnt told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Hi, Filters triggered by an Escalation, either via Set-Fields or Push-Fields, will ALWAYS be run in the same thread. This has ALWAYS been the case. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. -Original Message- Now that you remind me, I actually remember discussing this once with you.. I'll really need to log the workflow to see what thread processes the filter workflow when filters are executed triggered by the AR_ESCALATOR user. I was told this in a performance tuning class years ago (version 4.0 - 4.5 days so probably 11 or 12 years ago) that you let escalations perform first stage actions, and leave any 2nd and 3rd stage actions (deletes, push fields, notifications) to be performed by filters that are run using the admin thread. Maybe the design was different back then? So this is obsolete now? I wish I had a server to verify this :-) Joe -Original Message- From: LJ LongWing Sent: Thursday, December 08, 2011 2:18 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut you and I seem to differ in our opinions of how it works. So...based on your statement below, having the escalation set a field, and having a filter fire on that field being set, then performing the delete will be 'faster' because of a 'fire and forget' type of mechanism? I would argue that an action of delete within the escalation, and a setfield causing a filter to fire that causes the delete are 'the same', in that the escalation thread does not 'go onto the next record' till after the filters on the current record are done...so, in essence, the performance of either action would be the same and the escalation thread would still be tied up for exactly the same amount of time regardless At least, that's my understanding :) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 11:33 AM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry End Date as Linda pointed out should be a field on that form you are searching for, represented by 'End Date' in the qualification and not $End Date$.. That being said, LJ's suggestion is right.. The qualification should be in the Run If of the Escalation and the run process should be Application-Delete-Entry $SCHEMA$ $Request ID$ Having
Re: Application-Query-Delete-Entry
On the note of waiting for an Escalation to run have you noticed in recent releases of Dev Studio you can right click on an Escalation and select Run Now? It is there for both Time and Interval escalations. Nice addition! Jason On Sat, Dec 10, 2011 at 11:50 AM, Grooms, Frederick W frederick.w.gro...@xo.com wrote: From the Filter log (and this is even from Application-Query-Delete-Entry action) FLTR TID: 4027734928 RPC ID: 001637 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) /* Sat Dec 10 2011 13:27:52.0979 */ Start filter processing (phase 1) -- Operation - DELETE on MyFormName - 5840476 As you can see the filters fire using the Escalation thread. Application-Query-Delete-Entry is a benefit when deleting child form records. Take the example of the order with line items. Instead of pushing a value to each line item for the order, you execute the Application-Query-Delete-Entry in the delete of the order record to delete the child line items. The main reason for using a field to trigger a delete (using a Filter) for me, is I can then manually trigger the same Filters at any time I need to. It makes testing my workflow so much easier than waiting for an Escalation and searching thru the logs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto: arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Saturday, December 10, 2011 12:59 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasnt told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Hi, Filters triggered by an Escalation, either via Set-Fields or Push-Fields, will ALWAYS be run in the same thread. This has ALWAYS been the case. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. -Original Message- Now that you remind me, I actually remember discussing this once with you.. I'll really need to log the workflow to see what thread processes the filter workflow when filters are executed triggered by the AR_ESCALATOR user. I was told this in a performance tuning class years ago (version 4.0 - 4.5 days so probably 11 or 12 years ago) that you let escalations perform first stage actions, and leave any 2nd and 3rd stage actions (deletes, push fields, notifications) to be performed by filters that are run using the admin thread. Maybe the design was different back then? So this is obsolete now? I wish I had a server to verify this :-) Joe -Original Message- From: LJ LongWing Sent: Thursday, December 08, 2011 2:18 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut you and I seem to differ in our opinions of how it works. So...based on your statement below, having the escalation set a field, and having a filter fire on that field being set, then performing the delete will be 'faster' because of a 'fire and forget' type of mechanism? I would argue that an action of delete within the escalation, and a setfield causing a filter to fire that causes the delete are 'the same', in that the escalation thread does not 'go onto the next record' till after the filters on the current record are done...so, in essence, the performance of either action would be the same and the escalation thread would still be tied up for exactly the same amount of time regardless At least, that's my understanding :) -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Thursday, December 08, 2011 11:33 AM To: arslist@ARSLIST.ORG
Re: Application-Query-Delete-Entry
That sure is a cool feature – new addition... Does it work? :-) Yup those logs are indicative that filters run on the same thread. Delete from memory where instructions LIKE ‘%filters use a separate thread%’; commit transaction; Thanks for correcting me.. hopefully my memory wont rollback again to what I was taught :-) Joe From: Jason Miller Sent: Saturday, December 10, 2011 4:49 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry ** On the note of waiting for an Escalation to run have you noticed in recent releases of Dev Studio you can right click on an Escalation and select Run Now? It is there for both Time and Interval escalations. Nice addition! Jason On Sat, Dec 10, 2011 at 11:50 AM, Grooms, Frederick W frederick.w.gro...@xo.com wrote: From the Filter log (and this is even from Application-Query-Delete-Entry action) FLTR TID: 4027734928 RPC ID: 001637 Queue: Escalation Client-RPC: 390603 USER: AR_ESCALATOR (Pool 1) /* Sat Dec 10 2011 13:27:52.0979 */ Start filter processing (phase 1) -- Operation - DELETE on MyFormName - 5840476 As you can see the filters fire using the Escalation thread. Application-Query-Delete-Entry is a benefit when deleting child form records. Take the example of the order with line items. Instead of pushing a value to each line item for the order, you execute the Application-Query-Delete-Entry in the delete of the order record to delete the child line items. The main reason for using a field to trigger a delete (using a Filter) for me, is I can then manually trigger the same Filters at any time I need to. It makes testing my workflow so much easier than waiting for an Escalation and searching thru the logs. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza Sent: Saturday, December 10, 2011 12:59 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry That shatters a long standing understanding I had about data driven escalations. I had received this info at a Remedy training facility in Bracknell in UK years ago, that you ought to help Escalations with Filters triggered off modifications by the Escalation User in processing 2nd and 3rd stage actions. I guess they were wrong when they instructed us so then.. That is one of the benefit that they explained of having Filters running with a Run If of $USER$ = AR_ESCALATOR AND whatever else the rest of the qualification may be.. The other benefit I'm guessing (I wasnt told this but it makes sense) is if you need to override filter phasing during the run of an escalation.. Joe -Original Message- From: Misi Mladoniczky Sent: Saturday, December 10, 2011 4:04 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Hi, Filters triggered by an Escalation, either via Set-Fields or Push-Fields, will ALWAYS be run in the same thread. This has ALWAYS been the case. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11): * 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. -Original Message- Now that you remind me, I actually remember discussing this once with you.. I'll really need to log the workflow to see what thread processes the filter workflow when filters are executed triggered by the AR_ESCALATOR user. I was told this in a performance tuning class years ago (version 4.0 - 4.5 days so probably 11 or 12 years ago) that you let escalations perform first stage actions, and leave any 2nd and 3rd stage actions (deletes, push fields, notifications) to be performed by filters that are run using the admin thread. Maybe the design was different back then? So this is obsolete now? I wish I had a server to verify this :-) Joe -Original Message- From: LJ LongWing Sent: Thursday, December 08, 2011 2:18 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry Joe, I know this discussion comes up every once in awhilebut you and I seem to differ in our opinions of how it works. So...based on your statement below, having the escalation set a field, and having a filter fire on that field being set, then performing the delete will be 'faster' because of a 'fire and forget' type of mechanism? I would argue that an action of delete within the escalation, and a setfield causing a filter to fire that causes
Application-Query-Delete-Entry
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date
is more than 6 months prior to todays date. I built the escalation and
when I run it nothing happens. Can someone point in the right
directions with the Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without
setting a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
Try
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ('End Date' ($TIMESTAMP$ - (86400 * 180)))
'End Date' is the field on the form like 'Status'.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem to
differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete will
be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters on
the current record are done...so, in essence, the performance of either action
would be the same and the escalation thread would still be tied up for exactly
the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
Re: Application-Query-Delete-Entry
I was thinking the same thing.
On Thu, Dec 8, 2011 at 11:18 AM, LJ LongWing lj.longw...@gmail.com wrote:
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a
setfield causing a filter to fire that causes the delete are 'the same', in
that the escalation thread does not 'go onto the next record' till after
the filters on the current record are done...so, in essence, the
performance of either action would be the same and the escalation thread
would still be tied up for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList) [mailto:
arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation
would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status'
=
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Re: Application-Query-Delete-Entry
First, let me thank you for all the input.
I struggled with the Application-Delete-Entry $SCHEMA$ $Request ID$,
because the AP:Alternate form doesn't have a field called Request
ID. Upon further digging, from the clues you gave, I used the
following to get the results I was looking for.
Run If Qualification: ('Status' Current) AND ('End Date' ($DATE$
- (86400 * 180)))
Run Process:Application-Delete-Entry $SCHEMA$ $1$
I had to put the $SCHEMA$ inside of quotes and the $1$ field represents
the Alternate ID field in the form; found this hiding on the second tab.
Thanks again,
Larry B.
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
** I was thinking the same thing.
On Thu, Dec 8, 2011 at 11:18 AM, LJ LongWing lj.longw...@gmail.com
wrote:
Joe,
I know this discussion comes up every once in awhilebut you
and I seem to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a
field, and having a filter fire on that field being set, then performing
the delete will be 'faster' because of a 'fire and forget' type of
mechanism?
I would argue that an action of delete within the escalation,
and a setfield causing a filter to fire that causes the delete are 'the
same', in that the escalation thread does not 'go onto the next record'
till after the filters on the current record are done...so, in essence,
the performance of either action would be the same and the escalation
thread would still be tied up for exactly the same amount of time
regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you
are
searching for, represented by 'End Date' in the qualification
and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and
the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over
the entire
data table. You do not want to do that in case you have like a
million or
more records in it.. It may probably hang the escalation thread
waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for
deletion' using
a tag on a field created for that. This would mean that the
Escalation would
do a single update to that table which is a faster operation
that multiple
deletes and be done with it.. Create a filter that runs if the
$USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that
entry. So on a
fairly large set of data, although the deletes are still
potentially
happening triggered by that filter, the escalation thread has
already
finished processing the escalation and is ready to take on a new
job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit 'off'. An escalation performs a search
that matches
your qualification, and then performs your action on ALL records
that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 *
180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying 'that' record...so you
wouldn't want
to then perform an Application-Query-Delete-Entry, you could
simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the
End Date is
more than 6 months prior to todays date. I built the escalation
Re: Application-Query-Delete-Entry
$1$ is the same as $Request ID$ if a form when created, has not have had the
database name altered. In case of AP:Alternate, I think this has been altered
to Entry ID.. Check the database name..
That being said, its safer to use $1$ in your workflow as irrespective to
whatever changes are made to the database name of that field, it will always
work..
Joe
From: Larry Barnes
Sent: Thursday, December 08, 2011 3:10 PM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
**
First, let me thank you for all the input.
I struggled with the Application-Delete-Entry $SCHEMA$ $Request ID$, because
the AP:Alternate form doesn't have a field called Request ID. Upon further
digging, from the clues you gave, I used the following to get the results I was
looking for.
Run If Qualification: ('Status' Current) AND ('End Date' ($DATE$ -
(86400 * 180)))
Run Process:Application-Delete-Entry $SCHEMA$ $1$
I had to put the $SCHEMA$ inside of quotes and the $1$ field represents the
Alternate ID field in the form; found this hiding on the second tab.
Thanks again,
Larry B.
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
** I was thinking the same thing.
On Thu, Dec 8, 2011 at 11:18 AM, LJ LongWing lj.longw...@gmail.com wrote:
Joe,
I know this discussion comes up every once in awhilebut you and I seem to
differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete will
be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters on
the current record are done...so, in essence, the performance of either action
would be the same and the escalation thread would still be tied up for exactly
the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past
Re: Application-Query-Delete-Entry
Now that you remind me, I actually remember discussing this once with you..
I'll really need to log the workflow to see what thread processes the filter
workflow when filters are executed triggered by the AR_ESCALATOR user.
I was told this in a performance tuning class years ago (version 4.0 - 4.5
days so probably 11 or 12 years ago) that you let escalations perform first
stage actions, and leave any 2nd and 3rd stage actions (deletes, push
fields, notifications) to be performed by filters that are run using the
admin thread. Maybe the design was different back then? So this is obsolete
now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters
on the current record are done...so, in essence, the performance of either
action would be the same and the escalation thread would still be tied up
for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
I have also tried:Application-Query-Delete-Entry AP:Alternate
('Status' = Past) and ($End Date$ ($DATE$ - (86400 * 180)))
Thanks in advance for your time,
Larry B
_attend WWRUG12 www.wwrug.com ARSlist: Where the Answers Are_
Re: Application-Query-Delete-Entry
One of us should set this up and test it :)if either of us had that sort of
spare time :D
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 3:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Now that you remind me, I actually remember discussing this once with you..
I'll really need to log the workflow to see what thread processes the filter
workflow when filters are executed triggered by the AR_ESCALATOR user.
I was told this in a performance tuning class years ago (version 4.0 - 4.5
days so probably 11 or 12 years ago) that you let escalations perform first
stage actions, and leave any 2nd and 3rd stage actions (deletes, push
fields, notifications) to be performed by filters that are run using the
admin thread. Maybe the design was different back then? So this is obsolete
now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I seem
to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field, and
having a filter fire on that field being set, then performing the delete
will be 'faster' because of a 'fire and forget' type of mechanism?
I would argue that an action of delete within the escalation, and a setfield
causing a filter to fire that causes the delete are 'the same', in that the
escalation thread does not 'go onto the next record' till after the filters
on the current record are done...so, in essence, the performance of either
action would be the same and the escalation thread would still be tied up
for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not $End
Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the entire
data table. You do not want to do that in case you have like a million or
more records in it.. It may probably hang the escalation thread waiting for
it to complete..
Also a faster way to do it would be to 'mark that entry for deletion' using
a tag on a field created for that. This would mean that the Escalation would
do a single update to that table which is a faster operation that multiple
deletes and be done with it.. Create a filter that runs if the $USER$ is
AR_ESCALATOR and the flag for delete is set, to delete that entry. So on a
fairly large set of data, although the deletes are still potentially
happening triggered by that filter, the escalation thread has already
finished processing the escalation and is ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit ‘off’. An escalation performs a search that matches
your qualification, and then performs your action on ALL records that match
that qualification. So in this case, I would expect your run-if
qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying ‘that’ record…so you wouldn’t want
to then perform an Application-Query-Delete-Entry, you could simply perform
an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date is
more than 6 months prior to todays date. I built the escalation and when I
run it nothing happens. Can someone point in the right directions with the
Run Process syntax.
I'm using SQL 2008 and Windows 2008. ITSM is 7.5
The form I'm deleting from is: AP:Alternate
Run IF Qualification is:'Status' = Past (also tried without setting
a Run If Qualification)
Run Process is:Application-Query-Delete-Entry AP:Alternate ('Status' =
Past) and ($End
Re: Application-Query-Delete-Entry
Going out on a limb here, since this is all new to me. It appears to me
that both methods are needed depending on the form you are working with.
The CAI:EventParmsInterface from has a field called Deleted which when
set to True will trigger workflow to delete the entry.
The AP:Alternate form doesn't appear to have a field to set that would
trigger backend workflow to delete these records thus the need for the
Run Process command line : Application-Delete-Entry SCHEMA$ $1$
The $1$ is the Alternate ID field in this form
Larry B
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 2:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Now that you remind me, I actually remember discussing this once with
you..
I'll really need to log the workflow to see what thread processes the
filter workflow when filters are executed triggered by the AR_ESCALATOR
user.
I was told this in a performance tuning class years ago (version 4.0 -
4.5 days so probably 11 or 12 years ago) that you let escalations
perform first stage actions, and leave any 2nd and 3rd stage actions
(deletes, push fields, notifications) to be performed by filters that
are run using the admin thread. Maybe the design was different back
then? So this is obsolete now?
I wish I had a server to verify this :-)
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 2:18 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Joe,
I know this discussion comes up every once in awhilebut you and I
seem to differ in our opinions of how it works.
So...based on your statement below, having the escalation set a field,
and having a filter fire on that field being set, then performing the
delete will be 'faster' because of a 'fire and forget' type of
mechanism?
I would argue that an action of delete within the escalation, and a
setfield causing a filter to fire that causes the delete are 'the same',
in that the escalation thread does not 'go onto the next record' till
after the filters on the current record are done...so, in essence, the
performance of either action would be the same and the escalation thread
would still be tied up for exactly the same amount of time regardless
At least, that's my understanding :)
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Joe Martin D'Souza
Sent: Thursday, December 08, 2011 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
End Date as Linda pointed out should be a field on that form you are
searching for, represented by 'End Date' in the qualification and not
$End Date$..
That being said, LJ's suggestion is right..
The qualification should be in the Run If of the Escalation and the run
process should be
Application-Delete-Entry $SCHEMA$ $Request ID$
Having an Escalation with no Run If instructs it to be run over the
entire data table. You do not want to do that in case you have like a
million or more records in it.. It may probably hang the escalation
thread waiting for it to complete..
Also a faster way to do it would be to 'mark that entry for deletion'
using a tag on a field created for that. This would mean that the
Escalation would do a single update to that table which is a faster
operation that multiple deletes and be done with it.. Create a filter
that runs if the $USER$ is AR_ESCALATOR and the flag for delete is set,
to delete that entry. So on a fairly large set of data, although the
deletes are still potentially happening triggered by that filter, the
escalation thread has already finished processing the escalation and is
ready to take on a new job..
Joe
-Original Message-
From: LJ LongWing
Sent: Thursday, December 08, 2011 12:54 PM Newsgroups:
public.remedy.arsystem.general
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry
Larry,
Your approach is a bit 'off'. An escalation performs a search that
matches your qualification, and then performs your action on ALL records
that match that qualification. So in this case, I would expect your
run-if qualification to be
('Status' = Past) and ($End Date$ ($TIMESTAMP$ - (86400 * 180)))
Or, whatever qual you want to identify your specific records,
Then, from there, you will be modifying 'that' record...so you wouldn't
want to then perform an Application-Query-Delete-Entry, you could simply
perform an
Application-Delete-Entry $SCHEMA$ $Request ID$
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Larry Barnes
Sent: Thursday, December 08, 2011 10:23 AM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry
**
Hello Listers,
I'm trying to learn how to delete records that are past and the End Date
is more than 6 months prior
Problems with the Command Application-Query-Delete-Entry
** Hi,I have a problem with the command in an AL@@:Application-Query-Delete-Entry CHG:CABInvitedPeople 'Change ID+' = $Infrastructure Change ID$Im getting alwayws the error message error in the qualificationBut in the documents of ARS there is the same example with the correct arguments.Any advice is very appreciated !Tristan _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
Re: Problems with the Command Application-Query-Delete-Entry
I am going off my memory here so I could be wrong. We could not get it to work formatted like it is in the manual either. I think we had to format as below: @@:Application-Query-Delete-Entry CHG:CABInvitedPeople '' = $Infrastructure Change ID$ where x is the DB ID rather than name hope that helps. Todd Arner From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of tristan.rop...@t-online.de Sent: Tuesday, October 05, 2010 6:09 AM To: arslist@ARSLIST.ORG Subject: Problems with the Command Application-Query-Delete-Entry ** Hi, I have a problem with the command in an AL @@:Application-Query-Delete-Entry CHG:CABInvitedPeople 'Change ID+' = $Infrastructure Change ID$ Im getting alwayws the error message error in the qualification But in the documents of ARS there is the same example with the correct arguments. Any advice is very appreciated ! Tristan _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: Problems with the Command Application-Query-Delete-Entry
Yup. It's a documentation fail I reported over a year ago. Use the field ID, not the field name. Rick On Tue, Oct 5, 2010 at 8:10 AM, Arner, Todd tar...@glhec.org wrote: ** I am going off my memory here so I could be wrong. We could not get it to work formatted like it is in the manual either. I think we had to format as below: @@:Application-Query-Delete-Entry CHG:CABInvitedPeople '' = $Infrastructure Change ID$ where x is the DB ID rather than name hope that helps. Todd Arner -- *From:* Action Request System discussion list(ARSList) [mailto: arsl...@arslist.org] *On Behalf Of *tristan.rop...@t-online.de *Sent:* Tuesday, October 05, 2010 6:09 AM *To:* arslist@ARSLIST.ORG *Subject:* Problems with the Command Application-Query-Delete-Entry ** Hi, I have a problem with the command in an AL @@:Application-Query-Delete-Entry CHG:CABInvitedPeople 'Change ID+' = $Infrastructure Change ID$ Im getting alwayws the error message error in the qualification But in the documents of ARS there is the same example with the correct arguments. Any advice is very appreciated ! Tristan _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. _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: Problems with the Command Application-Query-Delete-Entry
** Hi,Many thanks, i solved the issue already.Life is a bitch.Tristan-Original Message-Date: Tue, 05 Oct 2010 14:20:19 +0200Subject: Re: Problems with the Command Application-Query-Delete-EntryFrom: Rick Cook remedyr...@gmail.comTo: arslist@ARSLIST.ORG** Yup. It's a documentation fail I reported over a year ago. Use the field ID, not the field name.RickOn Tue, Oct 5, 2010 at 8:10 AM, Arner, Todd tar...@glhec.org wrote:** I am going off my memory here so I could be wrong. We could not get it to work formatted like it is in the manual either. I think we had to format as below:@@:Application-Query-Delete-Entry CHG:CABInvitedPeople '' = $Infrastructure Change ID$where x is the DB ID rather than namehope that helps.Todd ArnerFrom: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of tristan.rop...@t-online.deSent: Tuesday, October 05, 2010 6:09 AMTo: arslist@ARSLIST.ORGSubject: Problems with the Command Application-Query-Delete-Entry** Hi,I have a problem with the command in an AL@@:Application-Query-Delete-Entry CHG:CABInvitedPeople 'Change ID+' = $Infrastructure Change ID$Im getting alwayws the error message error in the qualificationBut in the documents of ARS there is the same example with the correct arguments.Any advice is very appreciated !Tristan_attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ The information contained in this communication may be confidential, is intended only for the use of the recipient(s) named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately and destroy or delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
Re: Problems with the Command Application-Query-Delete-Entry
I believe it depends on the DB Name verses the Field Label. When the 2 are the
same then the name will work in the run process action. It is when they are
different that you have problems (especially when the form has multiple views).
Using the ID will always work.
I have also had it require you to put the qualification into parenthesis
('' = $Infrastructure Change ID$) in order for it to work.
Fred
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of tristan.rop...@t-online.de
Sent: Tuesday, October 05, 2010 7:39 AM
To: arslist@ARSLIST.ORG
Subject: Re: Problems with the Command Application-Query-Delete-Entry
**
Hi,
Many thanks, i solved the issue already.
Life is a bitch.
Tristan
-Original Message-
Date: Tue, 05 Oct 2010 14:20:19 +0200
Subject: Re: Problems with the Command Application-Query-Delete-Entry
From: Rick Cook remedyr...@gmail.com
To: arslist@ARSLIST.ORG
** Yup. It's a documentation fail I reported over a year ago. Use the field
ID, not the field name.
Rick
-Original Message-
On Tue, Oct 5, 2010 at 8:10 AM, Arner, Todd tar...@glhec.org wrote:
**
I am going off my memory here so I could be wrong. We could not get it to work
formatted like it is in the manual either. I think we had to format as below:
@@:Application-Query-Delete-Entry CHG:CABInvitedPeople '' =
$Infrastructure Change ID$
where x is the DB ID rather than name
hope that helps.
Todd Arner
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of tristan.rop...@t-online.de
Sent: Tuesday, October 05, 2010 6:09 AM
To: arslist@ARSLIST.ORG
Subject: Problems with the Command Application-Query-Delete-Entry
**
Hi,
I have a problem with the command in an AL
@@:Application-Query-Delete-Entry CHG:CABInvitedPeople 'Change ID+' =
$Infrastructure Change ID$
Im getting alwayws the error message error in the qualification
But in the documents of ARS there is the same example with the correct
arguments.
Any advice is very appreciated !
Tristan
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Application-Query-Delete-Entry
Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Application Query Delete Entry
Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application Query Delete Entry
Turn on SQL logging on as well. It is probably failing there, and this will tell you why. Also, I would try using a numeric value for the expression: 'chkBoxApplicationStatus' = 0 (or whatever the value is for Delete) Steve On Jan 8, 6:27 am, Kaushal Pandya kaushal.coold...@gmail.com wrote: Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application Query Delete Entry
Review the run process documentation esp. relating to Active Links. You will need to prefix the command with @@: so that it runs on the server. This is also abundantly documented in this arslist. Cheers Ben Chernys www.softwaretoolhouse.com _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kaushal Pandya Sent: January 8, 2009 12:28 PM To: arslist@ARSLIST.ORG Subject: Application Query Delete Entry ** Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. __Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
AW: Application Query Delete Entry
If you're using this in an AL you must precede the command with @@: The AL runs on the client and try's to start an executable file named Application-Query-Delete-Entry. -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 12:53 An: arslist@ARSLIST.ORG Betreff: Re: Application Query Delete Entry Turn on SQL logging on as well. It is probably failing there, and this will tell you why. Also, I would try using a numeric value for the expression: 'chkBoxApplicationStatus' = 0 (or whatever the value is for Delete) Steve On Jan 8, 6:27 am, Kaushal Pandya kaushal.coold...@gmail.com wrote: Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application Query Delete Entry
Hi friends, thanks for your help... @@ has solved my problem. Thanks folks for you help once again. - Kaushal. On Jan 8, 5:15 pm, Conny Martin conny.mar...@t-systems.com wrote: If you're using this in an AL you must precede the command with @@: The AL runs on the client and try's to start an executable file named Application-Query-Delete-Entry. -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 12:53 An: arsl...@arslist.org Betreff: Re: Application Query Delete Entry Turn on SQL logging on as well. It is probably failing there, and this will tell you why. Also, I would try using a numeric value for the expression: 'chkBoxApplicationStatus' = 0 (or whatever the value is for Delete) Steve On Jan 8, 6:27 am, Kaushal Pandya kaushal.coold...@gmail.com wrote: Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application Query Delete Entry
Huh...didn't even notice the Log stating ACTLjust assumed filters. The documentation flags Application-Query-Delete-Entry as Filter only, and not Active Links. Does the lack of a checkbox mean it will work but isn't supported? Or is this just another example of bad documentation? For the record, I think it is bad, performance-wise, to delete x number of records via client-side code. This should be invoked via a filter. Steve On Jan 8, 7:56 am, kush kaushal.coold...@gmail.com wrote: Hi friends, thanks for your help... @@ has solved my problem. Thanks folks for you help once again. - Kaushal. On Jan 8, 5:15 pm, Conny Martin conny.mar...@t-systems.com wrote: If you're using this in an AL you must precede the command with @@: The AL runs on the client and try's to start an executable file named Application-Query-Delete-Entry. -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 12:53 An: arsl...@arslist.org Betreff: Re: Application Query Delete Entry Turn on SQL logging on as well. It is probably failing there, and this will tell you why. Also, I would try using a numeric value for the expression: 'chkBoxApplicationStatus' = 0 (or whatever the value is for Delete) Steve On Jan 8, 6:27 am, Kaushal Pandya kaushal.coold...@gmail.com wrote: Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:www.rmsportal.comARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
AW: Application Query Delete Entry
I think there is no problem with performance. The only API-Call which you'll
see is an ARExecuteProcessForActivelink. From then on all is running within the
server.
-Ursprüngliche Nachricht-
Von: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] Im Auftrag von ccrashh
Gesendet: Donnerstag, 8. Januar 2009 14:11
An: arslist@ARSLIST.ORG
Betreff: Re: Application Query Delete Entry
Huh...didn't even notice the Log stating ACTLjust assumed filters. The
documentation flags Application-Query-Delete-Entry as Filter only, and not
Active Links. Does the lack of a checkbox mean it will work but isn't
supported? Or is this just another example of bad documentation?
For the record, I think it is bad, performance-wise, to delete x number of
records via client-side code. This should be invoked via a filter.
Steve
On Jan 8, 7:56 am, kush kaushal.coold...@gmail.com wrote:
Hi friends,
thanks for your help...
@@ has solved my problem.
Thanks folks for you help once again.
-
Kaushal.
On Jan 8, 5:15 pm, Conny Martin conny.mar...@t-systems.com wrote:
If you're using this in an AL you must precede the command with @@:
The AL runs on the client and try's to start an executable file named
Application-Query-Delete-Entry.
-Ursprüngliche Nachricht-
Von: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] Im Auftrag von ccrashh
Gesendet: Donnerstag, 8. Januar 2009 12:53
An: arsl...@arslist.org
Betreff: Re: Application Query Delete Entry
Turn on SQL logging on as well. It is probably failing there, and this
will tell you why.
Also, I would try using a numeric value for the expression:
'chkBoxApplicationStatus' = 0 (or whatever the value is for Delete)
Steve
On Jan 8, 6:27 am, Kaushal Pandya kaushal.coold...@gmail.com wrote:
Hi Friends,
I am facing problem with 'Application-Query-Delete-Entry' process.
I have written this action like this:
Application-Query-Delete-Entry KP_UserApplicationForm
'chkBoxApplicationStatus' = Delete
to delete all the record for which 'chkBoxApplicationStatus' =
Delete.
while running on user tool its giving an error like:
The system cannot find the file specified.
and in log file it captures:
ACTL 1: Run Process
ACTL Application-Query-Delete-Entry
KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete
ACTL Process: Application-Query-Delete-Entry
KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete
ACTL Failed ACTL Return
Code: 01
Any idea what could be the reason for this?
Please help to resolve this issue.
Thanks in advance,
Kaushal.
__
_ UNSUBSCRIBE or access ARSlist Archives
atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist:Where
the Answers Are
___ UNSUBSCRIBE or access ARSlist Archives
atwww.arslist.orgPlatinumSponsor:www.rmsportal.comARSlist:Where the
Answers Are
___ UNSUBSCRIBE or access ARSlist Archives
atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist:Where the
Answers Are
__
_ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org
Platinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:
www.rmsportal.com ARSlist: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application Query Delete Entry
But won't this process, because it is initiated from the client-end, force the client to wait until the whole thing is completed? Or will the API-Call just trigger and then return as a completed process to the client? I don't use client-side Run Processes much, so haven't explored their impact. I could test this, but am lazy :) Steve On Jan 8, 8:16 am, Conny Martin conny.mar...@t-systems.com wrote: I think there is no problem with performance. The only API-Call which you'll see is an ARExecuteProcessForActivelink. From then on all is running within the server. -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 14:11 An: arsl...@arslist.org Betreff: Re: Application Query Delete Entry Huh...didn't even notice the Log stating ACTLjust assumed filters. The documentation flags Application-Query-Delete-Entry as Filter only, and not Active Links. Does the lack of a checkbox mean it will work but isn't supported? Or is this just another example of bad documentation? For the record, I think it is bad, performance-wise, to delete x number of records via client-side code. This should be invoked via a filter. Steve On Jan 8, 7:56 am, kush kaushal.coold...@gmail.com wrote: Hi friends, thanks for your help... @@ has solved my problem. Thanks folks for you help once again. - Kaushal. On Jan 8, 5:15 pm, Conny Martin conny.mar...@t-systems.com wrote: If you're using this in an AL you must precede the command with @@: The AL runs on the client and try's to start an executable file named Application-Query-Delete-Entry. -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 12:53 An: arsl...@arslist.org Betreff: Re: Application Query Delete Entry Turn on SQL logging on as well. It is probably failing there, and this will tell you why. Also, I would try using a numeric value for the expression: 'chkBoxApplicationStatus' = 0 (or whatever the value is for Delete) Steve On Jan 8, 6:27 am, Kaushal Pandya kaushal.coold...@gmail.com wrote: Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:www.rmsportal.comARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
AW: Application Query Delete Entry
If you're using Run Process regardless if filter or AL, it's always fire and forget. The process is started and the workflow isn't waiting for any response. If you're doing a Set-Field $PROCESS$, the workflow will wait for a response. Kind Regards Conny -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 14:53 An: arslist@ARSLIST.ORG Betreff: Re: Application Query Delete Entry But won't this process, because it is initiated from the client-end, force the client to wait until the whole thing is completed? Or will the API-Call just trigger and then return as a completed process to the client? I don't use client-side Run Processes much, so haven't explored their impact. I could test this, but am lazy :) Steve On Jan 8, 8:16 am, Conny Martin conny.mar...@t-systems.com wrote: I think there is no problem with performance. The only API-Call which you'll see is an ARExecuteProcessForActivelink. From then on all is running within the server. -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 14:11 An: arsl...@arslist.org Betreff: Re: Application Query Delete Entry Huh...didn't even notice the Log stating ACTLjust assumed filters. The documentation flags Application-Query-Delete-Entry as Filter only, and not Active Links. Does the lack of a checkbox mean it will work but isn't supported? Or is this just another example of bad documentation? For the record, I think it is bad, performance-wise, to delete x number of records via client-side code. This should be invoked via a filter. Steve On Jan 8, 7:56 am, kush kaushal.coold...@gmail.com wrote: Hi friends, thanks for your help... @@ has solved my problem. Thanks folks for you help once again. - Kaushal. On Jan 8, 5:15 pm, Conny Martin conny.mar...@t-systems.com wrote: If you're using this in an AL you must precede the command with @@: The AL runs on the client and try's to start an executable file named Application-Query-Delete-Entry. -Ursprüngliche Nachricht- Von: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] Im Auftrag von ccrashh Gesendet: Donnerstag, 8. Januar 2009 12:53 An: arsl...@arslist.org Betreff: Re: Application Query Delete Entry Turn on SQL logging on as well. It is probably failing there, and this will tell you why. Also, I would try using a numeric value for the expression: 'chkBoxApplicationStatus' = 0 (or whatever the value is for Delete) Steve On Jan 8, 6:27 am, Kaushal Pandya kaushal.coold...@gmail.com wrote: Hi Friends, I am facing problem with 'Application-Query-Delete-Entry' process. I have written this action like this: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete to delete all the record for which 'chkBoxApplicationStatus' = Delete. while running on user tool its giving an error like: The system cannot find the file specified. and in log file it captures: ACTL 1: Run Process ACTL Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Process: Application-Query-Delete-Entry KP_UserApplicationForm 'chkBoxApplicationStatus' = Delete ACTL Failed ACTL Return Code: 01 Any idea what could be the reason for this? Please help to resolve this issue. Thanks in advance, Kaushal. __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinumSponsor:www.rmsportal.comARSlist:Where the Answers Are __ __ ___ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum Sponsor:www.rmsportal.comARSlist:Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.orgPlatinum Sponsor:www.rmsportal.comARSlist: Where the Answers Are __ _ UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org Platinum
Re: Q: Application-Query-Delete-Entry
Yes, You could use this command from the Run Process or the setfield action
and define a qualification with values to be determined at run time.
Here is one of sample that works
Application-Query-Delete-Entry AR System Email Attachments ('18254' = 1
AND '179' = $Destination ID$)
AF
On Fri, May 2, 2008 at 11:51 AM, Tadeu Augusto Dutra Pinto
[EMAIL PROTECTED] wrote:
** Has anybody used Application-Query-Delete-Entry ?
Here are an example by Help of Admin Tool:
Application-Query-Delete-Entry ABC DEF 'User Name' = Fred
I would like to know if is possible to to something like this:
Application-Query-Delete-Entry ABC DEF 'User Name' = *$Name$*
**
Using a variable of another form...
Any tips ?
Thanks
*Tadeu Augusto Dutra Pinto*
-
IT Web Services ATM *Cinq Technologies*
http://www.cinq.com.brhttp://exchweb/bin/redir.asp?URL=http://www.cinq.com.br/
[EMAIL PROTECTED]
*Fone: 41 3018-2833 - Cinq*
-
*C*onfiabilidade, *In*ovação e *Q*ualidade em T.I.
__Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
html___
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: application query delete
Hi Fred, Uh duh of course!!! -- Regards, Louise van Hine [EMAIL PROTECTED] Quoting Grooms, Frederick W [EMAIL PROTECTED]: This is not a valid query 'Request' = $Request ID$ 'Status-Dtl' = Pending Since all you care about is Status of Pending use 'Status-Dtl' = Pending If you need Request ID and Status of Pending use an AND 'Request' = $Request ID$ AND 'Status-Dtl' = Pending Think of it as a normal Advanced Query in the User Tool Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of E. Louise van Hine Sent: Monday, October 29, 2007 2:02 PM To: arslist@ARSLIST.ORG Subject: Can anyone tell me what is wrong with this syntax in the Application-Query-Delete Entry? The out of box filter just queries for the Request ID, but I need it to only delete entries with the parameter where the Status is Pending. Can this command take two variables? Application-Query-Delete-Entry AP:Detail 'Request' = $Request ID$ 'Status-Dtl' = Pending -- Regards, Louise van Hine [EMAIL PROTECTED] ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
Hi, Also recieved the patch, and installed patch 5 on the development server. And yes, the error is gone... Regards, Jarl On 10/24/07, Emad Zaky [EMAIL PROTECTED] wrote: ** Hi, This is a defect. I had the exact same error. It appeared in patch 4 and was resolved in Patch 5 (we are still testing itbut that specific error is gone) Regards, Emad On 10/22/07, Ray Palla [EMAIL PROTECTED] wrote: ** I've seen this bug before and a better work around is to put a filter on the form to delete entry after all the other workflow is done... no loop needed. ISS03154144. R From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG ] On Behalf Of Joe D'Souza Sent: Monday, October 22, 2007 2:07 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... ** A workaround in case its a bug and you cannot use the Application-Query-Delete-Entry would be to use Application-Delete-Entry using a AL guide. Use the AL guide to loop through the records that have to be deleted, and pick the Entry ID of each of these records and use the Application-Delete-Entry to delete the individual entries while the workflow runs through that loop.. You may require to build a table field to have that guide run through that loop. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [ mailto:[EMAIL PROTECTED] Behalf Of Carey Matthew Black Sent: Monday, October 22, 2007 2:20 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Jarl, For some reason I actually think this is an old bug that has returned. I would suggest that you push BMC a bit to see if they can find an old bug related to this failure. If they can find it then they should reopen that old bug and tack more time on it. ( IMO ) An old ARSList post also suggests this: Thomas Bean date: Nov 7, 2005 3:50 PM snip In general, these seem to be the basic rules for creating the search qualification for this run process command: 1. The form name parameter does not need to be enclosed in double-quotes unless the form name contains spaces. 2. In the qualification, any fields in the target form need to be referenced by their field ID enclosed in single quotes. Fields from the current form need to be referenced by the field name enclosed by dollar signs, enclosed by double-quotes. 3. Parentheses can be added around qualification elements for clarity. Maybe if you update the action to use field ID's the problem could be avoided? -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 10/22/07, Jarl Grøneng [EMAIL PROTECTED] wrote: Defect SW00275269 is logged for this issue, should be fixed in patch 5... -- Jarl snip -Original Message- From: Action Request System discussion list(ARSList) [ mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl__20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
Hi, This is a defect. I had the exact same error. It appeared in patch 4 and was resolved in Patch 5 (we are still testing itbut that specific error is gone) Regards, Emad On 10/22/07, Ray Palla [EMAIL PROTECTED] wrote: ** I've seen this bug before and a better work around is to put a filter on the form to delete entry after all the other workflow is done... no loop needed. ISS03154144. R -- *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Joe D'Souza *Sent:* Monday, October 22, 2007 2:07 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: Application-Query-Delete-Entry and server crash... ** A workaround in case its a bug and you cannot use the Application-Query-Delete-Entry would be to use Application-Delete-Entry using a AL guide. Use the AL guide to loop through the records that have to be deleted, and pick the Entry ID of each of these records and use the Application-Delete-Entry to delete the individual entries while the workflow runs through that loop.. You may require to build a table field to have that guide run through that loop. Cheers ** *Joe D'Souza* -Original Message- From: Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG arslist@ARSLIST.ORG]On Behalf Of Carey Matthew Black Sent: Monday, October 22, 2007 2:20 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Jarl, For some reason I actually think this is an old bug that has returned. I would suggest that you push BMC a bit to see if they can find an old bug related to this failure. If they can find it then they should reopen that old bug and tack more time on it. ( IMO ) An old ARSList post also suggests this: Thomas Bean date: Nov 7, 2005 3:50 PM snip In general, these seem to be the basic rules for creating the search qualification for this run process command: 1. The form name parameter does not need to be enclosed in double-quotes unless the form name contains spaces. 2. In the qualification, any fields in the target form need to be referenced by their field ID enclosed in single quotes. Fields from the current form need to be referenced by the field name enclosed by dollar signs, enclosed by double-quotes. 3. Parentheses can be added around qualification elements for clarity. Maybe if you update the action to use field ID's the problem could be avoided? -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 10/22/07, Jarl Grøneng [EMAIL PROTECTED] wrote: Defect SW00275269 is logged for this issue, should be fixed in patch 5... -- Jarl snip -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG arslist@ARSLIST.ORG]On Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
BMC support is working on the issue. But want to see if other has the same issue. -- Jarl On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote: ** Nothing wrong with the syntax. It looks like an issue with the patch. Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Sunday, October 21, 2007 2:41 AM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... I see... This is the command... $PROCESS$ @@:Application-Query-Delete-Entry TMS:Flow 'RootRequestInstanceID' = $InstanceId$ AND 'ParentID' = $InstanceId$ AND 'Sequence Mode' = Yes AND 'Status' = Pending However, the active link runs fine on path 2, but with patch 4 the server crash... -- Jarl On 10/21/07, Dylan [EMAIL PROTECTED] wrote: I think what he's asking is, what do you have on the Run Process line? @@:Application-Query-Delete-Entry something something Wants to know what the something something is :) Just copy and paste the whole line into here. Easier to troubleshoot if you can see the exact syntax. Dylan -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 10:06 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Thats no problem, can query the string, and also delete them manually. -- Jarl On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote: ** Jarl, What's your query on the run process following the command Application-Query-Delete-Entry Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
I have always had problems with the Query-Delete-Entry unless I put the query
string inside parenthesis (so it see's the query as a single parameter).
Out of curiosity try that:
$PROCESS$ @@:Application-Query-Delete-Entry TMS:Flow
('RootRequestInstanceID' = $InstanceId$ AND 'ParentID' = $InstanceId$ AND
'Sequence Mode' = Yes AND 'Status' = Pending)
Fred
-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]
On Behalf Of Jarl Grøneng
Sent: Sunday, October 21, 2007 1:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry and server crash...
I see... This is the command...
$PROCESS$ @@:Application-Query-Delete-Entry TMS:Flow
'RootRequestInstanceID' = $InstanceId$ AND 'ParentID' = $InstanceId$ AND
'Sequence Mode' = Yes AND 'Status' = Pending
However, the active link runs fine on path 2, but with patch 4 the server
crash...
--
Jarl
On 10/21/07, Dylan [EMAIL PROTECTED] wrote:
I think what he's asking is, what do you have on the Run Process line?
@@:Application-Query-Delete-Entry something something
Wants to know what the something something is :)
Just copy and paste the whole line into here. Easier to troubleshoot
if you can see the exact syntax.
Dylan
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng
Sent: Saturday, October 20, 2007 10:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry and server crash...
Thats no problem, can query the string, and also delete them manually.
--
Jarl
On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote:
**
Jarl,
What's your query on the run process following the command
Application-Query-Delete-Entry
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng
Sent: Saturday, October 20, 2007 3:22 PM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry and server crash...
Hi,
We see that the server crash when running this active link:
INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow
This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry.
If we change the active link to do a Run Process
@@:Application-Query-Delete-Entry, this shows up in
arerror.log:
Failure during an attempt to perform an application command (ARERR
4554)Application-Query-Delete-Entry TMS:Flow ..
ARS 7.01 patch 4
Solaris 9
Oracle 9
ITSM7 patch 4
Running patch 2 also crash the server, but then its the notify
function that crash the server...
--
Jarl
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Application-Query-Delete-Entry and server crash...
Defect SW00275269 is logged for this issue, should be fixed in patch 5...
--
Jarl
On 10/22/07, Grooms, Frederick W [EMAIL PROTECTED] wrote:
I have always had problems with the Query-Delete-Entry unless I put the query
string inside parenthesis (so it see's the query as a single parameter).
Out of curiosity try that:
$PROCESS$ @@:Application-Query-Delete-Entry TMS:Flow
('RootRequestInstanceID' = $InstanceId$ AND 'ParentID' = $InstanceId$ AND
'Sequence Mode' = Yes AND 'Status' = Pending)
Fred
-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL
PROTECTED] On Behalf Of Jarl Grøneng
Sent: Sunday, October 21, 2007 1:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry and server crash...
I see... This is the command...
$PROCESS$ @@:Application-Query-Delete-Entry TMS:Flow
'RootRequestInstanceID' = $InstanceId$ AND 'ParentID' = $InstanceId$ AND
'Sequence Mode' = Yes AND 'Status' = Pending
However, the active link runs fine on path 2, but with patch 4 the server
crash...
--
Jarl
On 10/21/07, Dylan [EMAIL PROTECTED] wrote:
I think what he's asking is, what do you have on the Run Process line?
@@:Application-Query-Delete-Entry something something
Wants to know what the something something is :)
Just copy and paste the whole line into here. Easier to troubleshoot
if you can see the exact syntax.
Dylan
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng
Sent: Saturday, October 20, 2007 10:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Query-Delete-Entry and server crash...
Thats no problem, can query the string, and also delete them manually.
--
Jarl
On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote:
**
Jarl,
What's your query on the run process following the command
Application-Query-Delete-Entry
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng
Sent: Saturday, October 20, 2007 3:22 PM
To: arslist@ARSLIST.ORG
Subject: Application-Query-Delete-Entry and server crash...
Hi,
We see that the server crash when running this active link:
INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow
This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry.
If we change the active link to do a Run Process
@@:Application-Query-Delete-Entry, this shows up in
arerror.log:
Failure during an attempt to perform an application command (ARERR
4554)Application-Query-Delete-Entry TMS:Flow ..
ARS 7.01 patch 4
Solaris 9
Oracle 9
ITSM7 patch 4
Running patch 2 also crash the server, but then its the notify
function that crash the server...
--
Jarl
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the
Answers Are
Re: Application-Query-Delete-Entry and server crash...
Jarl, For some reason I actually think this is an old bug that has returned. I would suggest that you push BMC a bit to see if they can find an old bug related to this failure. If they can find it then they should reopen that old bug and tack more time on it. ( IMO ) An old ARSList post also suggests this: Thomas Bean date: Nov 7, 2005 3:50 PM snip In general, these seem to be the basic rules for creating the search qualification for this run process command: 1. The form name parameter does not need to be enclosed in double-quotes unless the form name contains spaces. 2. In the qualification, any fields in the target form need to be referenced by their field ID enclosed in single quotes. Fields from the current form need to be referenced by the field name enclosed by dollar signs, enclosed by double-quotes. 3. Parentheses can be added around qualification elements for clarity. Maybe if you update the action to use field ID's the problem could be avoided? -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 10/22/07, Jarl Grøneng [EMAIL PROTECTED] wrote: Defect SW00275269 is logged for this issue, should be fixed in patch 5... -- Jarl snip -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
A workaround in case its a bug and you cannot use the Application-Query-Delete-Entry would be to use Application-Delete-Entry using a AL guide. Use the AL guide to loop through the records that have to be deleted, and pick the Entry ID of each of these records and use the Application-Delete-Entry to delete the individual entries while the workflow runs through that loop.. You may require to build a table field to have that guide run through that loop. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Carey Matthew Black Sent: Monday, October 22, 2007 2:20 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Jarl, For some reason I actually think this is an old bug that has returned. I would suggest that you push BMC a bit to see if they can find an old bug related to this failure. If they can find it then they should reopen that old bug and tack more time on it. ( IMO ) An old ARSList post also suggests this: Thomas Bean date: Nov 7, 2005 3:50 PM snip In general, these seem to be the basic rules for creating the search qualification for this run process command: 1. The form name parameter does not need to be enclosed in double-quotes unless the form name contains spaces. 2. In the qualification, any fields in the target form need to be referenced by their field ID enclosed in single quotes. Fields from the current form need to be referenced by the field name enclosed by dollar signs, enclosed by double-quotes. 3. Parentheses can be added around qualification elements for clarity. Maybe if you update the action to use field ID's the problem could be avoided? -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 10/22/07, Jarl Grøneng [EMAIL PROTECTED] wrote: Defect SW00275269 is logged for this issue, should be fixed in patch 5... -- Jarl snip -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.5/1085 - Release Date: 10/22/2007 10:35 AM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
I've seen this bug before and a better work around is to put a filter on the form to delete entry after all the other workflow is done... no loop needed. ISS03154144. R _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Monday, October 22, 2007 2:07 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... ** A workaround in case its a bug and you cannot use the Application-Query-Delete-Entry would be to use Application-Delete-Entry using a AL guide. Use the AL guide to loop through the records that have to be deleted, and pick the Entry ID of each of these records and use the Application-Delete-Entry to delete the individual entries while the workflow runs through that loop.. You may require to build a table field to have that guide run through that loop. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG mailto:[EMAIL PROTECTED] Behalf Of Carey Matthew Black Sent: Monday, October 22, 2007 2:20 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Jarl, For some reason I actually think this is an old bug that has returned. I would suggest that you push BMC a bit to see if they can find an old bug related to this failure. If they can find it then they should reopen that old bug and tack more time on it. ( IMO ) An old ARSList post also suggests this: Thomas Bean date: Nov 7, 2005 3:50 PM snip In general, these seem to be the basic rules for creating the search qualification for this run process command: 1. The form name parameter does not need to be enclosed in double-quotes unless the form name contains spaces. 2. In the qualification, any fields in the target form need to be referenced by their field ID enclosed in single quotes. Fields from the current form need to be referenced by the field name enclosed by dollar signs, enclosed by double-quotes. 3. Parentheses can be added around qualification elements for clarity. Maybe if you update the action to use field ID's the problem could be avoided? -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 10/22/07, Jarl Grøneng [EMAIL PROTECTED] wrote: Defect SW00275269 is logged for this issue, should be fixed in patch 5... -- Jarl snip -Original Message- From: Action Request System discussion list(ARSList) [ mailto:arslist@ARSLIST.ORG mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
I see... This is the command... $PROCESS$ @@:Application-Query-Delete-Entry TMS:Flow 'RootRequestInstanceID' = $InstanceId$ AND 'ParentID' = $InstanceId$ AND 'Sequence Mode' = Yes AND 'Status' = Pending However, the active link runs fine on path 2, but with patch 4 the server crash... -- Jarl On 10/21/07, Dylan [EMAIL PROTECTED] wrote: I think what he's asking is, what do you have on the Run Process line? @@:Application-Query-Delete-Entry something something Wants to know what the something something is :) Just copy and paste the whole line into here. Easier to troubleshoot if you can see the exact syntax. Dylan -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 10:06 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Thats no problem, can query the string, and also delete them manually. -- Jarl On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote: ** Jarl, What's your query on the run process following the command Application-Query-Delete-Entry Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are __ NOD32 2604 (20071019) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
Nothing wrong with the syntax. It looks like an issue with the patch. Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Sunday, October 21, 2007 2:41 AM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... I see... This is the command... $PROCESS$ @@:Application-Query-Delete-Entry TMS:Flow 'RootRequestInstanceID' = $InstanceId$ AND 'ParentID' = $InstanceId$ AND 'Sequence Mode' = Yes AND 'Status' = Pending However, the active link runs fine on path 2, but with patch 4 the server crash... -- Jarl On 10/21/07, Dylan [EMAIL PROTECTED] wrote: I think what he's asking is, what do you have on the Run Process line? @@:Application-Query-Delete-Entry something something Wants to know what the something something is :) Just copy and paste the whole line into here. Easier to troubleshoot if you can see the exact syntax. Dylan -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 10:06 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Thats no problem, can query the string, and also delete them manually. -- Jarl On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote: ** Jarl, What's your query on the run process following the command Application-Query-Delete-Entry Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.15.5/1084 - Release Date: 10/21/2007 3:09 PM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Application-Query-Delete-Entry and server crash...
Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
Jarl, What's your query on the run process following the command Application-Query-Delete-Entry Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.15.3/1082 - Release Date: 10/20/2007 2:59 PM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
Thats no problem, can query the string, and also delete them manually. -- Jarl On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote: ** Jarl, What's your query on the run process following the command Application-Query-Delete-Entry Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: Application-Query-Delete-Entry and server crash...
I think what he's asking is, what do you have on the Run Process line? @@:Application-Query-Delete-Entry something something Wants to know what the something something is :) Just copy and paste the whole line into here. Easier to troubleshoot if you can see the exact syntax. Dylan -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 10:06 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Query-Delete-Entry and server crash... Thats no problem, can query the string, and also delete them manually. -- Jarl On 10/21/07, Joe D'Souza [EMAIL PROTECTED] wrote: ** Jarl, What's your query on the run process following the command Application-Query-Delete-Entry Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jarl Grøneng Sent: Saturday, October 20, 2007 3:22 PM To: arslist@ARSLIST.ORG Subject: Application-Query-Delete-Entry and server crash... Hi, We see that the server crash when running this active link: INT:CHGTMS:CRQ:ChangeSequence_OneLevelUp_ReBuildFlow This does a Set Field with a $PROCESS\$ Application-Query-Delete-Entry. If we change the active link to do a Run Process @@:Application-Query-Delete-Entry, this shows up in arerror.log: Failure during an attempt to perform an application command (ARERR 4554)Application-Query-Delete-Entry TMS:Flow .. ARS 7.01 patch 4 Solaris 9 Oracle 9 ITSM7 patch 4 Running patch 2 also crash the server, but then its the notify function that crash the server... -- Jarl __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are __ NOD32 2604 (20071019) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
