Hi Rick, I was getting the error's when I used that command. I just ended up archiving the form and setting to delete. This is how I'm cleaning up my email notifications since I don't delete after it sends. I'm running on ARS 6.3, so it was showing up back then as well.
Steve On Thu, May 29, 2008 at 1:03 PM, Rick Cook <[EMAIL PROTECTED]> wrote: > ** 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___ > > > __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"
