Or you can add a field to the form that says delete, then the escalation
will run and set the field to deleting. Then a filter that fires on
modify to delete the record. That way escalations are not tied up
deleting and the actual delete happens in filter which is fast.
*Rocky*
Rocky Rockwell
Remedy/BMC Application Designer
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Ph#1: 214-567-8874
Ph#2: 325-450-5076
Phil Murnane wrote:
**
In circumstances like this, I've always put the escalation on the
Group form, with a qualification of Group ID = 0 ("Public"). Since
the form name in the Run Process is decoupled from the form the
escalation is attached to, this works. It has another benefit in that
the Group form has few records, and is usually pinned in memory in the
database, so the query is low cost.
FWIW,
--Phil
PS: I have no idea why the error messages would appear on some servers
and not on others. :/
----- Original Message ----
From: Craig Carter <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Thursday, May 29, 2008 1:44:46 PM
Subject: Re: Application-Delete-Query-Entry gives errors
**
Absolutely it would be more efficient and I agree that is
preferred—the trick is to figure out a way to simply call it once
versus for every record in the table. As mentioned previously, you
could enable your escalation against a one record table used
specifically to issue single commands like this against other tables
but there should be a way to handle this within the same table.
It is interesting that it appears to work on all of your other servers
though without any problem so perhaps there is something set up to
handle this situation?
Craig Carter
Software Engineer, RSP
------------------------------------------------------------------------
*From:* Action Request System discussion list(ARSList) [mailto:
arslist@ARSLIST.ORG ] *On Behalf Of *Rick Cook
*Sent:* Thursday, May 29, 2008 2:34 PM
*To:* arslist@ARSLIST.ORG
*Subject:* Re: Application-Delete-Query-Entry gives errors
** As I understand it, using the call I'm using,
(Application-Query-Delete-Entry)/ /is more efficient for multiple
deletes than Application-Delete-Entry. I haven't tested that, but it
seems to make sense. It is like deleting a list of entries on your
screen at once instead of one at a time. At very least, it should cut
out the GLE call to refresh the entry list after each delete.
Rick
On Thu, May 29, 2008 at 1:19 PM, Craig Carter
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
**
True—but as Fred mentioned, you are calling the full delete for every
record. If you put the qualification in the Run If and delete them
using request id and Application-Delete-Entry, it may solve your problem.
Craig Carter
Software Engineer, RSP
------------------------------------------------------------------------
*From:* Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG>] *On Behalf
Of *Rick Cook
*Sent:* Thursday, May 29, 2008 2:07 PM
*To:* arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG>
*Subject:* Re: Application-Delete-Query-Entry gives errors
** No, that's on Application-Delete-Entry. The syntax for
/Application-Query-Delete-Entry* */is /Application-Query-Delete-Entry
"<form>" <qualification_string>.
/Rick
On Thu, May 29, 2008 at 12:57 PM, Craig Carter
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
**
I believe you have to use the Request ID field with this command.
Since you are not providing that, you get the entry error.
Craig Carter
Software Engineer, RSP
------------------------------------------------------------------------
*From:* Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG>] *On Behalf
Of *Rick Cook
*Sent:* Thursday, May 29, 2008 1:52 PM
*To:* arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG>
*Subject:* Application-Delete-Query-Entry gives errors
** We are running an escalation nightly that runs this command:
*/Application-Query-Delete-Entry "SHR:TmpMessages" (( 'Status' =
"Sent") AND ( 'Send Time' != $NULL$ ))/*. The effect is to clear a
form that contains records accumulated during the day, but which are
no longer needed.
Running this creates thousands of entries in the arerror.log file
(roughly, but not exactly, equivalent to the number of records in the
form) that say this: */Thu May 29 10:31:45 2008 390603 : Entry does
not exist in database (ARERR 302)/*.
There are no errors that show up in the api or sql logs, and the
records DO get deleted. Any idea why these errors appear? I'm kinda
stumped as to where else to look for a cause.
Rick
__Platinum Sponsor: www.rmsportal.com <http://www.rmsportal.com/>
ARSlist: "Where the Answers Are" html___
__Platinum Sponsor: www.rmsportal.com <http://www.rmsportal.com/>
ARSlist: "Where the Answers Are" html___
__Platinum Sponsor: www.rmsportal.com <http://www.rmsportal.com/>
ARSlist: "Where the Answers Are" html___
__Platinum Sponsor: www.rmsportal.com <http://www.rmsportal.com/>
ARSlist: "Where the Answers Are" html___
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___
__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"
