Question

Print error when trying to print Picklist in batch

  • 14 October 2022
  • 4 replies
  • 144 views
AndyPurdey
Rank
Userlevel 1
Badge +5

I have created a job for the user base that is printing picking lists as IFS App, when the user runs picking lists manually there is no issue, but running as a scheduled process the print fails with the following error (we are running Apps 9)  -

 

Unable to get database connection.

(Transaction BEA1-7CAF5733F485BAAA5AB5 not active anymore.

tx status = Marked rollback.

[Reason=weblogic.transaction.internal.AppSetRollbackOnlyException:

setRollbackOnly called on transaction]) Caused by:

Transaction BEA1-7CAF5733F485BAAA5AB5 not active anymore.

tx status = Marked rollback.

[Reason=weblogic.transaction.internal.AppSetRollbackOnlyException:

setRollbackOnly called on transaction]

 

If anyone can advise a solution, it would be appreciated.

Thanks

4 replies

D
Rank
Userlevel 2
Badge +6

Hi AndyPurdey,

 

one of my customers had this issue this week. It was caused by a report rule. 

Check if there are any report rules for this report. If yes deactivate them and try again. 

 

Best regards,

Darius  

/Darius
A
Rank
Badge +2

@AndyPurdey > I was wondering if you ever found an answer to this? We are experiencing a very similar problem and getting the same error message. For us it is typically on one of the first few documents printed each morning. Interested to hear if you ever found an answer that might help us? Thanks :) 

AndyPurdey
Rank
Userlevel 1
Badge +5

Hi AshT, 

It was a while ago, if I remember rightly, I think we just deleted the process and resubmitted it again as IFSAPP.  Sorry I can’t be of much more help.

 

Regards

Andy

H
Rank
Userlevel 1
Badge +4

Hi All,

We has the similar error for a customer and was able to solve by increasing DB parameter “open_cursors”.

When generating reports or print jobs it could open several cursors and there could be several SQL statements running as there are plenty of reports/prints that need to be generated at once. Hence I suspected this issue occurs when a cursor is open but not closed during loop execution. However, this can occur when a recursive method (where a cursor exists) call exists inside a loop as well.

Check the current value,

SELECT value FROM v$parameter WHERE name = 'open_cursors';

 

And increase the value to higher than existing one.

ALTER SYSTEM SET open_cursors = <VALUE_HIGHER_THAN_EXISTING> SCOPE=BOTH;

Best Regards,
Hashan

Best Regards, HashanD

Reply


Terms & ConditionsCookie settings