No, Michelle, this is not part of a server group - yet. The error might make more sense if it were, or if we were running Application-Delete-Entry, which we're not. The error seems as if it's running a GetListEntry after each delete, which I didn't think it was, and then reporting the error after each of those Gets. I have more to noodle and test on tomorrow, for sure.
Thanks for your input! Rick On Thu, May 29, 2008 at 3:29 PM, Michelle L <[EMAIL PROTECTED]> wrote: > ** > 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] <[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] <arslist@ARSLIST.ORG>] *On Behalf Of *Rick Cook* > Sent:* Thursday, May 29, 2008 2:07 PM* > To:* [EMAIL PROTECTED] <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] <[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] <arslist@ARSLIST.ORG>] *On Behalf Of *Rick Cook* > Sent:* Thursday, May 29, 2008 1:52 PM* > To:* [EMAIL PROTECTED] <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___ > > > ====================================================================== > 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. > ====================================================================== > __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"
