UBE R5742565 taking too much time for specific users

Kishor@jde

Active Member
I am facing wired issue with UBE R5742565 on JDE E1 9.0 .
For same order number working absolutely fine for one user and taking 20 min to other user .
Can someone help like how user role is related to UBE execution .
for most of user it is working ok but when it come to some specific user (4-5 users )
it took 20 min for successful execution.
I have checked log ,any suggestion are really helpful .

Thanks
Pintya
 
Any chance row security exists for the users who experience the slowdown?

Craig
 
You might want to generate debug log from both and then compare to find where its taking longer.

Chan
 
Activate the logs in the report and ask for another execution.
Also, it's the same exactly version? It might be his own computer rather than any other issue with JDE.
 
Thanks for suggestion .
I am getting log as below :
I am confuse why it is working for some user and getting this error for others.

runbatch.c935
RUNBATCH: Remote CP=1252, Remote OS=1, Local CP=1252, ConvertToASCII=0


417960/-163027248 WRK:Starting jdeCallObject Thu Jun 2 11:27:27.230686 rtk_frms.c648
RUN0000066 - Warning - ProcOpt Data Size Mismatch: Requested 2198 is less than Retrieved 2220 for App P4210,Version VPG124.
Data Structure allocated successfully. This usually means items have been added to the template and existing
business function will function correctly.


417960/-163027248 WRK:Starting jdeCallObject Thu Jun 2 11:38:57.832320 k2pdfutils.c500
No output written to PDF by R5742565-VPG110. No PDF will be created.


417960/-163027248 WRK:Starting jdeCallObject Thu Jun 2 11:38:57.892092 zdrv.cpp384
Terminating Z driver


417960/-163027248 WRK:Starting jdeCallObject Thu Jun 2 11:38:57.892300 zdrv.cpp401
Calling freeSession


417960/-163027248 WRK:Starting jdeCallObject Thu Jun 2 11:38:58.037119 jdecache.c1502
CAC0001025 - Application code leaked 2 caches which were detected when freeing environment JQA910 (EnvHandle 09dfa988) for user Z071752.
 
Hello -

ProcOpt Data size mismatch is pretty common and nothing to worry (The message say bsfn will function correctly).

I would run two reports with same data selection (1. user have performance issue, 2.User does not have performance issue) with debug log ON (Debug log setting level = 5 or 6) and scan the log to determine what's going on and which sql statment is taking for ever.

Regards,
Mitu
 
Issue was regarding user profile setting Decimal Format Character .If we change value from , (comma) to decimal(.) for Decimal Format Character for that user its completed in time .if we change it back to comma(, ) again report taking too much time .

Qeus : due to localization we have to keep comma as Decimal Format Character for that user .how could this setting is related to report execution .It will be great help if someone can explain it .
 
Back
Top