Hi, Rick: I think you have the gist of what everyone's saying. You already know that it is more efficient to point that escalation at the group form where groupId=0 or 1...or whatever. I believe your question was related to the error messages you're receiving. And although you understand that there are different options for building the escalation, the point is that the escalation fires in other environments without error.
Since I've seen this behavior before, I have to ask. This server doesn't happen to be a part of a server group, where it is possible that the escalations attempted to run on more than one server did it? A similar phenomenon occurred here. We didn't usually see the Entry does not exist in database error on this particular escalation that runs nightly; so we knew something was wrong. We found that the error was occurring in the arerror.log of one of the servers and not in the other. We then found that for whatever reason during the last update, the "Disable Escalations" configuration setting was unchecked on two out of three of our servers. In our case, two servers should have that option checked. The same thing happened with Archiving. It should only be enabled on one out of three of our servers. Not sure if that helps or not. Thanks, Michelle Rick Cook <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <arslist@ARSLIST.ORG> 05/29/2008 03:33 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Application-Delete-Query-Entry gives errors [pjm] ** 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-Entry is 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___ ====================================================================== Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. ====================================================================== _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
