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.