TD-22038: Failed To Create bulk PDF Creations - Waiting since 2011

[Sunil]

Hello,

I am following up this issue since 2011 and due to this , i am unable to migrate application to TD41 To TD60,TD61,TD62 and Not TD63. I don't know why Gupta team unable to see this issue.

This error normally comes when generate PDF in Bulk say 3000 To 10000.

Regards.
Sunil

[Sunil]

Hello Support,

This error comes when we create PDF (Using SalReportPrintToFile formatType =2 ) in bulk otherwise this work perfect. So How can i create Test case .

Exception:

Message :
Conditional expression :
Filename :
Function :
Linenumber:1463.


I can show on various our customer PC and due to this , i am not able to use TD60,TD61,TD62 and Now TD63.

Regards.
Sunil

[Sunil]

Yes Apaula,

I am able to repro this case zip attached , this zip file will contains the following files.

1. PDFErrorTestApplication.apt
2. test.csv - application will read record from this file one by one and create PDF file in folder c:\Test
3. Test.qrp - Required in application.
4. PDF error.txt file , this is file generated when i was running application inhouse.

Note : Please also check memory usage of cbi62.exe usage increase substantially after few records create which indicate issue of Memory Usage .

Please let me know if anything more required to escalate this issue.

Regards.
Sunil

[VEspinal]

Hi:

I've logged a defect: TD-22038: Failed To Create bulk PDF Reports

We will keep you informed on any updates.

Thanks for the information.

Thanks,
Victor Espinal

[FRBhote]

Same problem in TD 5.2

[VEspinal]

This was scheduled for 6.2 SP4

Thanks
Victor

[Sunil]

Hi Support,
I am waiting since long , can you tell us when TD62 sp4 will be released.

Regards.
Sunil

[ianrudge]

SP4? For 6.3?

[FRBhote]

SO there is no hope for 5.2?

[ThomasSchuele]

PDFError.jpg

SalReportPrintToFile (2=PDF)

The problem still appears in TD 6.3 Update 2

Best regards, Thomas Schüle

[abota]

Is there a Fix/Workaround for this? I just stumbled across this Problem in TD6.2 SP4

Regards Alex

[Jeff Luther]

Folks -- let me jump into this discussion by answering Abota --

Yes, there is a workaround!

Here is a ittle background first: ReportBuilder (RB) is not 'reentrant' -- As Wikipedia (https://en.wikipedia.org/wiki/Reentrancy_(computing) )defines this for programming, a program is reentrant...

if it can be interrupted in the middle of its execution and then safely called again

RB does not work this way (and never did) and I can recall a number of past Forum postings that showed a 'bug' because of this limit in RB. Just like this thread of msgs.

The FIX: I will let Gupta decide if and when it can or will add reentrancy to RB. But in the meantime here is...

A WORKAROUND: The workaround is to simply code your reporting to be sure to allow RB to (I call it) 'settle down', that is completely close itself internally, before you call it again for another report. In the case of a Loop-type of reporting as the test case for this thread shows, this is required and without it RB couldn't clean up completely before being called again. And ending up with RB failing internally and yet with no error-handling (such as a Set hWndReport = ...) to the SalReport call to catch if the internal RB window was created OK or not.

I've coded an example of the workaround ( SalPause(() ) + some error- and iteration-handling coding to the test case so you can run this test x times to test. I've run this v5.2 version of the code for 50 reports in both v5.2 and v6.3 and in both cases it runs just fine and 50 test PDFs are created.

Couple notes:
> I added "JL" a as comment to anything I changed from the original test case.

> I have SalPause( 500 ) (1/2 second) coded in for my attached test. This works OK for a stub report as this test is coded; you may need to increase the 500 to something largeer for a 'real' report as it may take RB longer to 'settle down' and clear itself before exiting. Maybe 1-3 seconds (1000-3000ms) or so?

> I added Return TRUE to the early SAM_Report msgs. I think it's a good idea to do this.

> Note that if you rerun the code another x times the first set of reports is overwritten, so don't be fooled wondering what happened to this new set of x reports. As I was at first

> 'Workaround '' -- I know this is not a nice word for many coders; they want it done right . Well, I agree but in lieu of having reentrancy added to RB (or any other feature/bug you want to name), having a way to get your coding task done via a workaround is better than not a all.

[FRBhote]

Half a second is too much.

If I have 5000 reports to send - then it means a further 1.5 hours!

Unacceptable.

[Jeff Luther]

So put on your thinking cap and do some testing, FR. How about trying < 500ms? Nothing is free -- better ~1-1.5 hrs. longer than not at all

[FRBhote]

Taken an agency for Acrobat!