One more possibility of error 302.
If you have escalation logs enabled during the time of an error. They you may
see something like this:
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > /* Wed Feb 26 2014 00:35:54.3740 */Checking
FND:ACT:IM1-ProcessUPDATEASSOCATIONSTATUS (enabled) : ready to fire now on
SYS:Action
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > --> Passed -- perform actions
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > 000000006392739
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > 0: Set Fields
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > Status (7) = 5
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > Set field action failed, errno=302
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > Entry does not exist in database
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > 000000006392740
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > 0: Set Fields
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > Status (7) = 5
<ESCL> <TID: 0000004000> <RPC ID: 0000118619> <Queue: Escalation> <Client-RPC:
390603 > <USER: AR_ESCALATOR (Pool 1) >
<Overlay-Group: 1 > /* Wed Feb 26 2014 00:35:54.5460
*/FND:ACT:IM1-ProcessUPDATEASSOCATIONSTATUS completed on SYS:Action (Elapsed
time: 0.1720 seconds)
If that is the case then there are chances that the SYS:Action record is
created, and z1d_Action is not set to DONOTDELETE, so filter
SYS:ACT:DeleteOnSubmit_050 Is run, and triggers the immediate delete of the
record, that then does the work. An escalation
FND:ACT:IM1-ProcessUPDATEASSOCATIONSTATUS matches the record before it is
deleted, but does not process it until after the delete, and thus you get the
302 error.
The reason for this is that there are two fields used 'Action' (for the
escalation) and 'z1D_action' for the filter, and the qualifications do not
exclude each other.
I do not have the knowledge of exactly how this is intended to work, to suggest
a full solution, but it needs to be made such that if the record should be
processed by the escalation (as I believe is the case here, as 'Action' =
"INCUPDATEGROUPLIST") then the filter does not fire. A possible solution, is
that for all values of 'Action' in the escalation qualification, the filters
that push to SYS:Action, need to include the value 'DONOTDELETE' in the
'z1D_Action' field, to prevent from SYS:ACT:DeleteOnSubmit_050 firing.
If you confirm it's a same behaviour in your case then you may need to modify
RUN IF qualification of above mentioned escalation and add something like this
to introduce a delay:
('Submit Date' < ($\TIMESTAMP$ - 120))"
Note: analyse and test it before you implement.
Regards,
Kiran
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Joe D'Souza
Sent: 18 March 2014 12:31
To: [email protected]
Subject: Re: Entry doesn't exist in Database(302)
Another possible reason for a 302 besides the record being physically deleted
is if you have Assignee Group functionality being used, and the user that tries
to access a particular record has no access to that record because of row
locking being turned on. I am quite certain you get a 302 when that is the
case, as for that user that record is as good as non existent. And I think that
is by design as the user has no right to know that record exists.
But as others have pointed out, 90% chance is that record is actually deleted
before it is accessed by workflow.
Cheers
Joe
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[email protected]] On Behalf Of Misi Mladoniczky
Sent: Monday, March 17, 2014 4:21 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: Entry doesn't exist in Database(302)
Hi,
Turn on your server logs for API/ESCL/FLTR/SQL and try to find out why you are
seeing this.
Presumably the record has been removed by an Application-Delete-Entry or
Application-Query-Delete-Entry call from an ACTL/FLTR/ESCL between the time the
user brings it up on screen in Modify-mode and then hits Save.
Search your definitions or logs for the above two delete calls.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Dears,
> please help as I facing a critical issue when alot of users modify
> some Tickets and causing to lose data.
> Thanks
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at
www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been
for 20 years"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
