Re: Application-Delete-Query-Entry gives errors
Actually, I kind of did this sideways. I created a field in the TmpDelete
form to hold the Form Name, and create one record for each Form that I might
want to delete records from. The Escalation then fires on *'Status' =
Active*, and runs *Application-Query-Delete-Entry $Form Name$ 'Status' =
Sent* (which is good for both forms).
Thanks again to all who helped me here, both on and offline.
Rick
On Fri, May 30, 2008 at 12:02 PM, Gary Opela (Corporate)
[EMAIL PROTECTED] wrote:
**
Rick,
On this new form you created, add a field called Escalation Name, and have
a Status values of Active and Inactive.
This way, on your escalation, you can run it against this form where
'Escalation Name' = Name of the current escalation AND 'Status' = Active
This allows you to use the form for multiple escalations in the future, and
it also allows you to easily turn the escalation on and off without having
to modify the escalation itself.
Thanks,
Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
*Best Product, Best People, Best Price**TM*
*An ISO 9001:2000 Certified, CMMI(R) Level 3 Rated Company***
--
*From:* Action Request System discussion list(ARSList) [mailto:
[EMAIL PROTECTED] *On Behalf Of *Rick Cook
*Sent:* Friday, May 30, 2008 1:49 PM
*To:* arslist@ARSLIST.ORG
*Subject:* Re: Application-Delete-Query-Entry gives errors
** RESOLVED. Thanks to all who contributed to my now-enhanced knowledge
level.
OK, here is what I've done to resolve this.
I created a small form with just the core fields, and created one record in
that form.
I then restructured my escalation to go against that one-record form,
running the Application-Query-Delete-Entry SHR:NotificationMessages
('Status' = Sent) from there.
The escalation ran one time, and took 2.5 minutes to delete 62k records.
No 302 errors. Yay!
Rick
On Fri, May 30, 2008 at 10:17 AM, Misi Mladoniczky [EMAIL PROTECTED] wrote:
Hi,
Does your escalation run on SHR:TmpMessages?
I would run it on some scheduler form, and it should trigger once (one
record).
The normal way to find out what the problem is would be to turn on logging.
What happens when you try to delete one record from the user tool?
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.
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
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
--
This message was scanned by ESVA and is believed to be clean.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
__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
Re: Application-Delete-Query-Entry gives errors
Hi, Does your escalation run on SHR:TmpMessages? I would run it on some scheduler form, and it should trigger once (one record). The normal way to find out what the problem is would be to turn on logging. What happens when you try to delete one record from the user tool? Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are -- This message was scanned by ESVA and is believed to be clean. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
RESOLVED. Thanks to all who contributed to my now-enhanced knowledge level.
OK, here is what I've done to resolve this.
I created a small form with just the core fields, and created one record in
that form.
I then restructured my escalation to go against that one-record form,
running the Application-Query-Delete-Entry SHR:NotificationMessages
('Status' = Sent) from there.
The escalation ran one time, and took 2.5 minutes to delete 62k records. No
302 errors. Yay!
Rick
On Fri, May 30, 2008 at 10:17 AM, Misi Mladoniczky [EMAIL PROTECTED] wrote:
Hi,
Does your escalation run on SHR:TmpMessages?
I would run it on some scheduler form, and it should trigger once (one
record).
The normal way to find out what the problem is would be to turn on logging.
What happens when you try to delete one record from the user tool?
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.
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
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
--
This message was scanned by ESVA and is believed to be clean.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
Rick,
On this new form you created, add a field called Escalation Name, and have a
Status values of Active and Inactive.
This way, on your escalation, you can run it against this form where
'Escalation Name' = Name of the current escalation AND 'Status' = Active
This allows you to use the form for multiple escalations in the future, and it
also allows you to easily turn the escalation on and off without having to
modify the escalation itself.
Thanks,
Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED]
On Behalf Of Rick Cook
Sent: Friday, May 30, 2008 1:49 PM
To: arslist@ARSLIST.ORG
Subject: Re: Application-Delete-Query-Entry gives errors
** RESOLVED. Thanks to all who contributed to my now-enhanced knowledge level.
OK, here is what I've done to resolve this.
I created a small form with just the core fields, and created one record in
that form.
I then restructured my escalation to go against that one-record form, running
the Application-Query-Delete-Entry SHR:NotificationMessages ('Status' =
Sent) from there.
The escalation ran one time, and took 2.5 minutes to delete 62k records. No
302 errors. Yay!
Rick
On Fri, May 30, 2008 at 10:17 AM, Misi Mladoniczky [EMAIL
PROTECTED]mailto:[EMAIL PROTECTED] wrote:
Hi,
Does your escalation run on SHR:TmpMessages?
I would run it on some scheduler form, and it should trigger once (one
record).
The normal way to find out what the problem is would be to turn on logging.
What happens when you try to delete one record from the user tool?
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.
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
___
UNSUBSCRIBE or access ARSlist Archives at
www.arslist.orghttp://www.arslist.org
Platinum Sponsor: www.rmsportal.comhttp://www.rmsportal.com ARSlist: Where
the Answers Are
--
This message was scanned by ESVA and is believed to be clean.
___
UNSUBSCRIBE or access ARSlist Archives at
www.arslist.orghttp://www.arslist.org
Platinum Sponsor: www.rmsportal.comhttp://www.rmsportal.com ARSlist: Where
the Answers Are
__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
Re: Application-Delete-Query-Entry gives errors
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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
Rick, If I had to guess the server is getting the list of entries (GLE API call) then deleting each entry one at at time AND doing a GetEntry _after_ it did the delete. (And the part that is producing the error is the GetEntry call, but it is ignored and the deleting continues.) I wonder if this is a known error in your specific ARS server version? (AKA: It sounds like the bug is that the ARS server [Escalation thread] is logging errors that are, and should be, ignored. It is not an error to not find the data after you told the application server to delete it. ) I would suggest that you open an incident with BMC tech support and see what they say. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On Thu, May 29, 2008 at 3:52 PM, Rick Cook [EMAIL PROTECTED] wrote: ** 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
Hi Rick, Try this for the escalation - Run Ifnbsp; qualifier - (( 'Status' = Sent) AND ( 'Send Time' !=nbsp; $NULL$ ) Run Process - Application-Delete-Entry SHR:TmpMessages $Request ID$ Frank Ginny Sr. Remedy Admin / Developer ** We are running an escalation nightly that runs this command:nbsp; Application-Query-Delete-Entry SHR:TmpMessages (( 'Status' = Sent) AND ( 'Send Time' !=nbsp; $NULL$ )).nbsp; 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:nbsp; Thu May 29 10:31:45 2008nbsp; 390603 : Entry does not exist in database (ARERR 302)pangt;. There are no errors that show up in the api or sql logs, and the records DO get deleted.nbsp; Any idea why these errors appear?nbsp; I'm kinda stumped as to where else to look for a cause. Rick ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
It sounds like you are running the escalation against the SHR:TmpMessages form. What is happening is the list of records to modify is being queried for and then the command is being executed against each of the records. Since the command deletes all of the records then the next record to process no longer exists. You should be receiving the error for n-1 records (since it will fail for records 2 and up). I would recommend changing to the Application-Delete-Entry command Application-Delete-Entry $SCHEMA$ $Request ID$ The other possible solution is to run the escalation against a different form that has only 1 record. Fred From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Thursday, May 29, 2008 2: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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
OK, as I expected, some answers that make sense at various levels. Now that I got answers unbiased by this next, let me drop the other shoe. The exact same escalation runs on another 7.1 server using the same environment (OS/DBMS/ARS) versions without the errors. In addition to these two 7.1 servers, I have it running on two 6.3 servers without the errors, too. That would tend to minimize the bug possibility, but it doesn't make me understand why the servers are acting differently. So what's different about this server? Beats me. I've looked at everything in the install, running daemons, conf files, etc. that I can think of, and there doesn't appear to be any difference. I'll keep looking, though. Any new ideas? Rick On Thu, May 29, 2008 at 1:06 PM, Frank Ginny [EMAIL PROTECTED] wrote: ** Hi Rick, Try this for the escalation - Run If qualifier - *(( 'Status' = Sent) AND ( 'Send Time' != $NULL$ ) Run Process - Application-Delete-Entry **SHR:TmpMessages $Request ID$ *Frank Ginny Sr. Remedy Admin / Developer *** * ** 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)pan*. 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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
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-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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
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:[EMAIL PROTECTED] 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-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___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: Where the Answers Are
Re: Application-Delete-Query-Entry gives errors
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
Re: Application-Delete-Query-Entry gives errors
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
Re: Application-Delete-Query-Entry gives errors
Actually the Delete still happens using the Escalation thread so it is tied up while the delete is processing. You can tell this by looking at the filter logs and seeing that the filter is running under RPC 390603. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Rockwell Sent: Thursday, May 29, 2008 4:49 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Delete-Query-Entry gives errors 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
Re: Application-Delete-Query-Entry gives errors [pjm]
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
Re: Application-Delete-Query-Entry gives errors
This is running on 390603, which is why we're multi-threading the Escalations in real life. I have to say that running this against another form is a new concept for me, though it makes more sense as I think more about it. I must have missed that day in training, because this is the first I've heard of it. :) I have also just heard that running it in the Else action vs. the If action will ensure that the action only fires once. Don't know why, but I'll give it a shot. Rick On Thu, May 29, 2008 at 3:24 PM, Grooms, Frederick W [EMAIL PROTECTED] wrote: Actually the Delete still happens using the Escalation thread so it is tied up while the delete is processing. You can tell this by looking at the filter logs and seeing that the filter is running under RPC 390603. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Rockwell Sent: Thursday, May 29, 2008 4:49 PM To: arslist@ARSLIST.ORG Subject: Re: Application-Delete-Query-Entry gives errors 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
Re: Application-Delete-Query-Entry gives errors [pjm]
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
Re: Application-Delete-Query-Entry gives errors [pjm]
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
