Hi,
I am trying to generate a report in PDF format and it is giving me this error.
FILE IS DAMAGED, COULD NOT BE REPAIRED

When I run the report in HTML or EXCEL, the report is working fine, but when I run the report in PDF format it is giving me the error. I am not sure if this is related to WebFocus or if it is related to PDF?
I tried limiting the total number of records range (where recordlimit eq '8000') and it works in PDF format whereas if I remove the recordlimit and try to run the report in PDF, it does not show the report.
Could someone tell me how to fix this error?

Thanks.

RB... I've found with PDF that my WebFocus isn't the only thing that doesn't work... Do you have a PDF file that you could open outside of WebFocus and verify that your Adobe works....

Sometimes the code will work just fine to HTML output, but when you go to PDF format there is a hidden error that selecting PDF doesn't work.

When I encouter this I set exit points and run with -set &echo = all; to find the hidden error.

If that's not the issue, sometime back we had this issue with caster and it turned out to be an issue with the antivirus software and the caster process.

My adobe is working fine. I was able to run other PDF reports and I also checked the other pdf documents outside of WebFOCUS.
Like Leah suggested, I did some exit points with -set &echo=all, but no luck. I did not find any hidden errors when I looked at the source code(by doing view source).
My guess is that the report is too large to handle in PDF. Could that be the reason?
Also, I did run the report using these commands and the reports runs fine in PDF.
My problem now is I do not want the grid to be seen. If I set the GRID off then the report gives me the same error. Page is damaged and cannot be repaired.

ON TABLE SET STYLE *
UNITS=IN, PAGESIZE='C', LEFTMARGIN=0.2500000, RIGHTMARGIN=0.250000,
TOPMARGIN=0.250000, BOTTOMMARGIN=0.250000, SQUEEZE=ON, ORIENTATION=LANDSCAPE, GRID=ON, $

TYPE=REPORT, SIZE=20, $

END STYLE

What Version of WebFOCUS are you running

4.3.5

I have received this error in the past with PDF files "FILE IS DAMAGED, COULD NOT BE REPAIRED"
when doing a compound report. Any chance this is a compound report you are trying to produce?

I know this sounds silly, but have you tried just removing the grid = on/off from the style command.

Carol, this report is not a compund report. I never encountered this problem before. Not sure why it is doing that.

Leah,
I tried removing the grid setting and ran the report. it is giving me the same error.

Why

TYPE=REPORT, SIZE=20, $

That seems a little excessive, doesn't it?

1) Try commenting out the TYPE=REPORT, SIZE=20, $

2) Try commenting out some columns, in case the report is too wide.

3) Try adding a recordlimit, to verify if it's actually the size of the PDF file that's the problem WHERE RECORDLIMIT EQ 100

PDF is very particular in regards to the structure of the document. If any object in the PDF file is out of sequence, mislabeled, missing, etc you'll receive that error. We generate our own PDF from scratch so sometimes ojects get "out of whack" in certain situations. In other words you have more than likely encountered a bug related to our PDF driver and should call Customer Support. There may be a patch for this.

Brian

I tried all ways to get the report running with out any errors. I should check with my admin about this error. Anyways, my users are happy with grid on. so, I decided to leave the grid on for now.

Thank you all for your help.

I�ve seen that error when I have manually set the total column widths (using SQUEEZE=) greater then the width of the page

I got "File damaged and could not be repaired" error message with Webfocus 5.3 when I tried to generate PDF report and it was working fine with 4.3 version.

I tried to include "-EXIT" after the following statements at the end of the report and it was working out well.

....
....
END
-ENDSTYLE
-EXIT
-HTMLBEGIN
....
....
Once I removed the "-EXIT", it was throwing the same error.

Hi Sheeba,

Has this issue regarding the error message been resolved?

I ran a quick search about the error message and came across the following topics from Information Builder's online documents which may be of interest:

Summary: PDF: The file is damaged and could not be repaired.
http://techsupport.informationbuilders.com/known_problems/11812042.html

Summary: PDF:The file is damaged and could not be repaired w/ FONT=20
http://techsupport.informationbuilders.com/known_problems/70661089.html

You will need an InfoResponse userid/password to access these documents.

Hope this helps.

Cheers,

Kerry

I got this error as well, but only when I switched from CGI to Servlet. The error only occurred on (PDF) reports for which the columns spanned more than one page. The solution for us was to set redirection to 'no' for pdf files in mime.wfs.

I run into this frequently when the PDF spans more than one page. One quick solution if it works is to change your font size down to like an 8 or 9 and see if it works that way. (Basically cramming the report onto one page span). Problem is that size 8 font is not for elderly or hard of sight...it is teeny tiny.

This problem crops up quite a bit on other things as well...I've run into it on another report where a certain symbol set appeared in the right order. As Kerry mentioned, see those technical advices for other ideas.

I too faced this error in my compound reports. But when I changed </1 to " " in my subhead section, I didn't get that error. It seems weird but works.

Try adding

FOOTING
" "

Might work - worked for one of my customers but they were creating a compound report.

I also have a case open on this topic at the moment. Are you running through servlet or cgi? I have reports that work through cgi but not servlet under 7.1.1. In my investigation it looks like when your columns spill over the page width and the report is more than a page long you get this corrupt error. I found that if the report columns spill over but the rows fit on one page you end up with a two page report that displays. When you increase the rows to go past one page the corrupt error message appears. What I am guessing is that when webfocus formats the data it is putting the data from those far right columns onto page number two. It then puts other rows on page number two. When the document is renderd by adobe it has conflicts because it doesn't know what to do with two pages with the same page numbers (This is just a guess). Under cgi the report pdf is created correctly and squeeze will keep the columns to one page width.

I was looking through this. On damaged PDF, I found that if you happen to have an empty report in the process of creating the report and don't have
set emptyreport = on
either in the start of the process or as an on table set, PDF does not like you when using caster. Also, we faced this issue with PDF and the anti-virus we had on our WebFOCUS server, way back.