OPEN TABLE NOT CLOSED !!!!!

jdecoder

jdecoder

Well Known Member
I have a simple report with some joins involving F1721, F006 and F0911 etc… nothing unusual but while I run the report in local it gives me this error (Check attachment) but when I re login into JDE FAT it runs ok for the first time and next when u run it again it starts giving error.
I am also attaching the log just have a look, and suggest what could cause such behavior.

Query in Green
Error in Red

Thanks in Advance.
 

Attachments

  • 152895-Error screen.doc
    113.5 KB · Views: 308
Check jde.log File also...
 

Attachments

  • 152897-jde (Open Tbl Error).doc
    886 bytes · Views: 151
Hi jdecoder,

First of all, I miss your release, SP/TS level, etc. information.

Have you tried on an other client?
If yes, is this the scenario on it?

Just 2 shots in the dark:

#1.
Delete the well known 6 spec file and try again.

#2.
If you use DoCustomSection call(s) in your report, then double-check, whether are all called section is Condional?

Read you later & Regards,

Zoltán
 
I am sorry I dint post my configuration along with my issue.
Its
JDE 8.12
TS: 8.96.22

I tried running that report in another client and observed the same behavior. I have even deployed it to my PY and in the server it seems to be working fine. But defiantly something went wrong with that report/ related objects. The jobs done for the client but for me left a question mark.
I tried writing table I/O for close table still din made any difference

And regarding the well known 6 spec, are they: D:\e812\DV812\spec\glbltbl.xdb , ddtext.xdb, dddict.xdb, glbltbl.ddb, ddtext.ddb, dddict.ddb . This is some thing new for me can u please throw some more light on what files are you exactly talking about?? And on deleting do they get regenerated automatically?? What do these files correspond to?

I don’t think this will help since the issue persisted on other client. But still for the sake of knowledge tell me what those files are??

Also all called sections are conditional one based on F0911 and one on F4812H.
 
Those files are the data dictionary cache and global table spec cache. If you delete them, they will rebuild.

Doubt it is your problem unless you changed the DD or added/changed a table, but still worth a shot.
 
[ QUOTE ]

#1.
Delete the well known 6 spec file and try again.


[/ QUOTE ]

Tried this, dint help...
 
Most often this error is a result of not closing a table handle inside of a C BSFN.

Are you calling any BSFNs? If there are any table triggers that call a C BSFN and the C BSFN fails to close table handles, this could also be the problem.
 
Well it’s a simple report not much coding is present, just one standard BF to get company description that’s all. The error is related to the views in the report, every section I have called in the report give an error for the corresponding table of the related view. Also the tables on which I have performed table I/O's also dose not give this error
 
When you close and logout JDE and try again on the first time is doesn't apear ??..
 
What about the PDF error you're getting before the Open Table messages?

6768/6748 UNKNOWN Thu Nov 12 18:27:40.646000 PrtPDFGen.C124
UBE0000084 ERROR: Function: PDFDocGen_Create, Code: 1074397185, Message: A file error has occurred.

That may be causing the runtime engine to abort before doing its proper cleanup.

I'm assuming you don't get the PDF error when the report runs correctly.
 
[ QUOTE ]
When you close and logout JDE and try again on the first time is doesn't apear ??..

[/ QUOTE ]

Exactly, the first time or even some times it runs for the second time also, maximum 2 times and then that it gives up. And if you run some other report which is referring to the table that went into error, those UBEs also goes into error.
 
[ QUOTE ]

I'm assuming you don't get the PDF error when the report runs correctly.

[/ QUOTE ]

Yes I don’t get the PDF error when UBE runs OK… but I believe it is a resultant of what caused the OPEN TABLE error, in spite the log sequence says the PDF error was generated first. Just a thought…Because Acrobat issues should not interfere with UBE engine and this happens only with this specific object
 
Just for fun, try adding this to your fat client jde.ini [UBE] section

UBEDLIMemFileSys=1
 
Hey Jeremy,

It is "supposed" to change the way the PDF is built during a UBE run. This setting should keep the buffering output in memory rather than continually writing to a temp file. The UBE engine uses Datalogics PDF libs to create the PDF output (that is the "DLI" part of the setting). In theory it should run faster but consume more memory. Running with this setting may stop some of the mysterious i/o errors. I figured it was worth a shot ... haven't heard anything back yet.

Craig
 
[ QUOTE ]
Just for fun, try adding this to your fat client jde.ini [UBE] section

UBEDLIMemFileSys=1

[/ QUOTE ]


Here are the test results:
Test 1 : With UBEDLIMemFileSys=1, 10 Runs and 10 Successful Outputs
Test 2 : Without UBEDLIMemFileSys=1, 5 Runs and 4 Successful Outputs 5th one went into error
Test 3 : With UBEDLIMemFileSys=1, 10 Runs and 10 Successful Outputs

So it seems that you have solved the issue, Bravo. Thanks a lot Craig for your valuable inputs. I am proud to be the part of JDElist because of people like you.

It would be greatly appreciated if you could throw some more light on what this DLI set up actually dose. How is PDF generation interfering with the UBE? What are the possible side effects, if any, since this is not a default setup? And how come this dose not happen in server (Thank god it dint happen, else it would have been a havoc).

Thanks again.
 
Glad it worked for you. I had this setting in my notes from a similar issue a while ago. You should be able to find some references at the Oracle support site. See the post to JMR about my understanding of the setting.

I guess the UBE engine treats any PDF library errors as fatal and aborts. As the environment handle is released it checks for any open table handles and reports it to the log.

Why does it happen? Good question ... it may have to do with the amount of rows returned in a given section and how the output is buffered. Since you have a perfect test case, you may be able to do some testing to see if anything (other than the ini setting) alters the results.

Why is this not a default setting? Probably has not been tested enough and/or the issue has been rare.

One tip ... trust your logs and start at the top.
wink.gif


Craig
 
Hi Craig,

Thanks a lot for this jde.ini setting, which solved this issue.

I remembered your post and this setting recently helped out one desperated colleauge of mine from an exactly same scenario.

Regards,

Zoltán
 
Hi Jdecoder,

How did you resolve this issue in the end? I am having same issue at the moment.

Thanks
Regards
Jason
 
Back
Top