Skip to main content

I am running a Deferred_Call within an event that is creating a new print job for another operational report.  I then have setup a report rule to print that report.   Everything prints fine expect Im getting this error message in the background job from that custom api call.  Is there anyway to prevent these error messages?  I have moved the api call to different batch queues but it is still triggering.  Do I need to keep extending the time?

 

“Unable to register new print job. The same report is already being processed in print job p  ]. Please allow more time for it to finish.                    ORA-20110: PrintJobContents.ALREADYIN

Basically the logic is to check report, its parameters, printers and the user. All these parameters are same for two jobs and if the first job is still in waiting or working states, it doesn’t allow next job to post and this error raises. This is to prevent unnecessary jobs created by mistake. 

 

I suppose you already have a delay of at least 5 seconds or so, therefore normally that is enough for a job to process if it is not too large. We tend to see this error when there’s a problem and when the jobs get stuck at waiting. Check this and if you can confirm your jobs are not stuck at waiting then a possible solution would be to add a delay up to a time for the first job to move from waiting. Or else you can change any parameters, printer name or executed user. So that it allows a second job while first one is still in waiting/working. 


Hi Rusiru,

Thank you for your response.  They are not stuck and eventually the reports do print I’m just trying to avoid the background jobs.  So where would a implement a delay?  Would that be in my event or plsql code?  The two reports are not using the same printer but are implemented by the same user.

Thank you,

Anne


Hi Anne,

 

I suppose you are using a loop to create and print jobs. You must implement the delay inside that loop. For example you can use following in PLSQL. 

Dbms_Lock.Sleep(5000);

 

How long will it take your job to complete? If it takes more than 5 seconds, they you have to change the delay time. 


I wrote a monitoring script that sends a job to Crystal to see if it’s still alive. On the database side, I have this loop that waits until the job is complete, which you might be able to adapt for your purpose. (result_key and pdf_length are variables I declared in SQL*Plus.)

 

VARIABLE result_key NUMBER
VARIABLE pdf_length NUMBER

-- Wait until the PDF has been generated. Give up after some time.
DECLARE
waited_ NUMBER := 0;
BEGIN
WHILE :pdf_length IS NULL AND waited_ < 300 LOOP
dbms_lock.sleep(seconds => 1);
BEGIN
SELECT LENGTH(pdf)
INTO :pdf_length
FROM pdf_archive_tab
WHERE result_key = :result_key;
EXCEPTION WHEN NO_DATA_FOUND THEN
NULL;
END;
waited_ := waited_ + 1;
END LOOP;
dbms_output.put_line('waited_ = ' || waited_);
END;
/

 


Thank you for all the responses but the fix was actually on the event itself.  I had to set the event to only fire on the arrival flag and then in the event action look at when the old printed arrival flag = false and new is true.  These changes stopped the event from continuing to fire and only fire once eliminating the print error.