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
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.org<http://www.arslist.org>
> Platinum Sponsor: www.rmsportal.com<http://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<http://www.arslist.org>
Platinum Sponsor: www.rmsportal.com<http://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
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
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 [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] ] *On Behalf Of *Rick Cook* >> Sent:* Thursday, May 29, 2008 2:07 PM* >> To:* [EMAIL PROTECTED] * >> 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 >> "" . >> * >> 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 >> >> >> >> --
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] ] *On Behalf Of *Rick Cook* > Sent:* Thursday, May 29, 2008 2:07 PM* > To:* [EMAIL PROTECTED] * > 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 > "" . > * > 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] ] *On Behalf Of *Rick Cook* > Sent:* Thursday, May 29, 2008 1:52 PM* > To:* [EMAIL PROTECTED] * > 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 n
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 discuss
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)" 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 "" . 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 p
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
> "" .
>
> /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@ARSL
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
"" .
/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" htm
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 ""
.
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
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 "" . 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
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 > "" . > > *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
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
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 "" . 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
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
No, that's on Application-Delete-Entry. The syntax for * Application-Query-Delete-Entry*** is *Application-Query-Delete-Entry "" . *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
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 ___ 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
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"
