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"
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: 1: Run Process Application-Query-Delete-Entry "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" Process: Application-Query-Delete-Entry "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" Failed 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: 1: Run Process Application-Query-Delete-Entry "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" Process: Application-Query-Delete-Entry "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" Failed 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
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
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
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 wouldnt 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"
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 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"_ > > > ___
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 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 *
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 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, 20
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:Alte
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"
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@ARSL
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$ >
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 expe
Re: Application-Query-Delete-Entry
From the Filter log (and this is even from Application-Query-Delete-Entry action) /* 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 be
Re: Application-Query-Delete-Entry
Joe, I would definitely say that using filters has its benefits, including being able to do a series of things with their own run-if/else qualifications, in fact I do this all the time, but in the situation where you simply want to delete a record...I'm not sure there is a benefit :), except maybe the benefit of being able to delete the record with the same filter in both places, but with different triggers for the field :) -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 11:59 AM 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 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 >
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) > > > >/* 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 tha
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 wrote: From the Filter log (and this is even from Application-Query-Delete-Entry action) /* 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, a
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 t
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 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 th
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 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 >> >
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 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 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 modificati
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 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
Re: Application-Query-Delete-Entry
I had gone for my training class in the year 1999. I was fairly new to Remedy back then (exactly a years experience behind me) & took most things taught there to be the absolute truth. They had an whole section in PTT classes those days called Data Drive Escalations or something like that, during which this discussion had arose.. I wish I had preserved those documents. But when moving out of Kuwait, I chose to trash most of the heavy weight items which included loads of Remedy documentation. I might still have some of the really old Flashboard manuals though (black books) :-) Joe From: Rod Harris Sent: Monday, December 12, 2011 8:28 AM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: 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 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: Thurs
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 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: > 1: Run Process > Application-Query-Delete-Entry > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > Process: Application-Query-Delete-Entry > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > Failed > 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: 1: Run Process Application-Query-Delete-Entry "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" Process: Application-Query-Delete-Entry "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" Failed 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 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: > 1: Run Process > Application-Query-Delete-Entry > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > Process: Application-Query-Delete-Entry > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > Failed > 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 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 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: > > 1: Run Process > > Application-Query-Delete-Entry > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > Process: Application-Query-Delete-Entry > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > Failed > > 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 "ACTL"just 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 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 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 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: > > > 1: Run Process > > > Application-Query-Delete-Entry > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > Process: Application-Query-Delete-Entry > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > Failed > > > 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 "ACTL"just 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 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 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 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: > > > 1: Run Process > > > Application-Query-Delete-Entry > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > Process: Application-Query-Delete-Entry > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > Failed 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 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 "ACTL"....just 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 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 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 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: > > > > 1: Run Process > > > > Application-Query-Delete-Entry > > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > > Process: Application-Query-Delete-Entry > > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > > Failed 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 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 "ACTL"just 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 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 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 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: > > > > 1: Run Process > > > > Application-Query-Delete-Entry > > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > > Process: Application-Query-Delete-Entry > > > > "KP_UserApplicationForm" 'chkBoxApplicationStatus' = "Delete" > > > > Failed > > > > 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" > > > > ___
Q: Application-Query-Delete-Entry
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.br [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Fone: 41 3018-2833 - Cinq - Confiabilidade, Inovação e Qualidade em T.I. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
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"
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 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: 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
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
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 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
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: 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
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
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
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 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: 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.br<http://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: 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: 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 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: 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 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
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 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
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 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 ] *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 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 &g
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 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 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
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 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 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" and have been
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 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 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 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. > >
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 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 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 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
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"
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"
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 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 > > > > -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 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 > > > > -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 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 > > > > -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...
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 ]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 > > > > 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 > > > > > > > > -Original Message- > > > > > From: Action Request System discussion list(ARSList) > > > > > [mailto: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...
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 > > > > > > > > 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 > > > > > > > > > > > > -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"
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"_
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 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 To: 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 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"_ _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 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 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"