Application-Query-Delete-Entry

[Larry Barnes]

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

[kush]

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

[Kaushal Pandya]

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

[Dave Barber]

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

[Linda Bykowski]

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

[LJ LongWing]

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"

Re: Application-Query-Delete-Entry

[Joe Martin D'Souza]

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

[LJ LongWing]

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

[Jason Miller]

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

[Larry Barnes]

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

[Joe Martin D'Souza]

$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

[Joe Martin D'Souza]

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

[LJ LongWing]

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

[Larry Barnes]

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

[Misi Mladoniczky]

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

[Joe Martin D'Souza]

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

[Grooms, Frederick W]

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

[LJ LongWing]

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

[Jason Miller]

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

[Joe Martin D'Souza]

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

[Misi Mladoniczky]

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

[Rod Harris]

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

[Misi Mladoniczky]

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

[Rod Harris]

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

[Misi Mladoniczky]

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

[Joe Martin D'Souza]

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

[ccrashh]

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

[Ben Chernys]

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

[Conny Martin]

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

[kush]

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

[ccrashh]

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

[Conny Martin]

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

[ccrashh]

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

[Conny Martin]

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

[Tadeu Augusto Dutra Pinto]

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

[CRENSHAW, CRYSTAL]

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

[LJ LongWing]

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

[Grooms, Frederick W]

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

[Jason Miller]

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

[Jason Miller]

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

[Mueller, Doug]

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

[Grooms, Frederick W]

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

[Mueller, Doug]

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

[Grooms, Frederick W]

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

[Dave Barber]

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

[Andrew Fremont]

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

[Reiser, John J]

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

[Dave Barber]

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

[Arner, Todd]

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

[Reiser, John J]

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

[Jason Miller]

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

[Dave Barber]

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

[Brittain, Mark]

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

[Dave Barber]

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

[Conny Martin]

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...

[Jarl Grøneng]

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...

[Joe D'Souza]

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...

[Jarl Grøneng]

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...

[Dylan]

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...

[Jarl Grøneng]

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...

[Joe D'Souza]

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...

[Jarl Grøneng]

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...

[Grooms, Frederick W]

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...

[Jarl Grøneng]

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...

[Carey Matthew Black]

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...

[Joe D'Souza]

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...

[Ray Palla]

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...

[Emad Zaky]

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...

[Jarl Grøneng]

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

[tristan.rop...@t-online.de]

**
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

[Arner, Todd]

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

[Rick Cook]

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

[tristan.rop...@t-online.de]

**
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

[Grooms, Frederick W]

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"