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]> 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:[EMAIL PROTECTED]
On Behalf Of Rick Cook
Sent: Thursday, May 29, 2008 2:07 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Delete-Query-Entry gives errors
** No, that's on Application-Delete-Entry. The syntax for
Application-Query-Delete-Entryis Application-Query-Delete-Entry "<form>"
<qualification_string>.
Rick
On Thu, May 29, 2008 at 12:57 PM, Craig Carter <[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:[EMAIL PROTECTED]
On Behalf Of Rick Cook
Sent: Thursday, May 29, 2008 1:52 PM
To: 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 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___
__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"
