PDF Export Error

Posted by: minnar on 4 August 2017, 2:32 pm EST

  • Posted 4 August 2017, 2:32 pm EST


    Error is "ActiveReports PDF Export DLL: Internal Error. Out of memory or corrupt pages collection., 7002".
    Problem comes up with one of our clients, I can't reproduce the error here.
    The error occurs when trying to save the report as PDF file. AR version is
    All other exports (excel, rtf) work just fine. Application is running on terminal server.
    All about 50 reports consists of one to couple of hundred pages and every report causes the error.

    Reports can be viewed in the viewer.

    Error occurs only when using AR version, version which we used earlier, works ok.

  • Replied 4 August 2017, 2:32 pm EST

    If the reports can be shown in the viewer but not exported to PDF, there may be several things happening. First off, since this is terminal server, make sure that the user has proper permissions to the default printer. Secondly, if you can view the report but receive the corrupt pages error when you export it, I don't think you're exporting the same report you're viewing. Can you save the report object's pages collection to an RDF file by running reportobject.Pages.Save("C:\temp.rdf") before exporting the report's pages collection? Third, make sure the correct version of the ActiveReports DLLs are installed on that server. Versioning conflicts can cause the error you see.
  • Replied 4 August 2017, 2:32 pm EST

    You'll have to zip the file to attach it to the post. I'm not sure that I'll see the same problem if I export the report here, but I should be able to see if the problem is with the report generation or the export.
  • Replied 4 August 2017, 2:32 pm EST

    User permissions to the default printer are ok and I'm exporting the exact same report I'm viewing.

    Attatched temp.rdf file created on my local machine, environment is the same as close as possible to our clients terminal server.
    But like I said, I can't reproduce the error here.

    We have several independent apps that uses AR, most of them are still using
    Our client has our application A which is compiled with AR running on their terminal server.
    Then they installed our application B which is compiled with AR to their terminal server and with this installation AR dlls were also updated.
    After that application A reports can't be saved as PDF, but viewing or exporting to excel or rtf is working.
    Is backward compatibility broken in your dlls?

  • Replied 4 August 2017, 2:32 pm EST

    We should maintain backward compatibility from 1168 to 1253. Here's a few more ideas.

    One, are you distributing the 1253 PDF export Dll to that location? If not, it would be a good idea.

    Two, can you bring Application A back to your development location and run it with 1253 without recompiling it? It should work, but we did have some issues with backwards compatibility in build 1251.

    If all the above fails, I'll need the rdf file generated from the server that's failing.
  • Replied 4 August 2017, 2:32 pm EST

    The RDF file exports fine on my test machine. If the RDF file came from the server that's generating the failed export, then there may be something else wrong with that server. You may not have enough memory left on that server to generate the report without error. To test this, you can compile my sample project and move it to the server along with the temp.rdf file you sent me. If it runs and fails, then it's not a memory issue.
    The other possibility is that ActiveReports does not have permissions to create the temp files it needs to export the report. Also, make sure that the PDF Export DLL registered on that machine is the correct version.
  • Replied 4 August 2017, 2:32 pm EST

    I finally got the rdf file generated from the server, but now I can't get it attatched here, can I send it to your email? Size of the file is 6,25 MB.

    One, I'm distributing the 1253 PDF export Dll.

    Two, I can also bring Application A back to my development location with 1253 without recompiling it and it works.
  • Replied 4 August 2017, 2:32 pm EST

    Here's the attachment, hope you'll find out something. <img src="/emoticons/emotion-21.gif" alt="Yes" />
  • Replied 4 August 2017, 2:32 pm EST

    I run the test and it didn't fail. PDF Export DLL is the correct version and ActiveReports does have permission to create temp files, so it's a memory issue? It would probably be easiest to upgrade AR to solve this.
  • Replied 4 August 2017, 2:32 pm EST

    Yes, your previously attached prjPDFExport sample project works ok on the same terminal server.

    Difference between my app and your sample project is the location where the pdf is exported. The sample project that works is creating the pdf in the same directory where the sample app is (app.path). My app lets user choose the directory and they create the files to their own client drives. My app also works if pdf is created to the root directory of the app, but that is not an option.

    It seems that the problem has something to do with terminal servers security settings, but also something has to have changed in pdfexpt.dll, because if I install previous version from the same app that uses AR it works. And for example excel-export is working with this new version to the same directory where the pdf-export is failing.
  • Replied 4 August 2017, 2:32 pm EST

    Could you please attach the sample project so I can run the test.
  • Replied 4 August 2017, 2:32 pm EST

    If you used FileMon and don't see the files being created, then most likely that's the problem. There should be 2 or more temp files that briefly appear in the same directory as the root-level executeable calling the reports. Does my sample project work in your situation (terminal services, etc.)?
  • Replied 4 August 2017, 2:32 pm EST

    I'm still having the same problem. I've upgraded AR first to, then and finally to 2.3.1268 but it's not helping.
    I think it may have something to do with security settings, what has changed in pdfexpt.dll since version Version worked ok and now with the latest version other exports are still working, but not pdf.
    Does the new pdf-export create temp-files to different location or use different user? Do you have any tips for me how could I solve this?
    I've used Filemon to check and temp-files are not created.

  • Replied 4 August 2017, 2:32 pm EST

    Sorry about that. The sample is attached.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels