Invalid export DLL or export format

[Former Member]

I have created a code to export the report to excel and it works.. but when i use the export property of the crystal report viewer, all file format works except for the excel format and I am receiving this kind of message whenever I tried using export property of the crystal report viewer..

"Error in File rpt017 {4742A80B-0356-499C-9B57-BE59A69BD788}.rpt: Invalid export DLL or export format."

any idea? someone?

[Former Member · Accepted solution]

I solved this problem by adding this to the front of the path variable: C:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\win32_x86;

On my development machine I only had to restart Visual Studio, but on the server the whole system needed to restart.

A before-and-after modules comparison showed the following DLLs were added to WEBDEV.WEBSERVER.EXE after adding the path: CRHEAPALLOC.DLL, CRXF_XLS.DLL, CRXF_XLS_RES_EN.DLL, EXPORTMODELLER.DLL, LIBPNG10.DLL, U2DDISK.DLL, X3DDKEN.DLL

Although this fixes the problem it seems like an ugly hack and I hope there's a better way to do it. (Adding a reference to ExportModeller did not work for me.)

[former_member200290 · Accepted solution]

I solved this problem by adding this to the front of the path variable: C:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\win32_x86;

This is telling me that possibly one of our dependencies for our export dlls are being picked up somewhere else on the path. Having to reboot in this case is normal. What can happen is if one application does a load library call on XYZ.DLL, it will be loaded from applications current directory, then windir/system dir, then the path. However windows will have this cached now so next time LoadLibrary is called on XYZ.dll it pulls it directly from the cache (unless of course a path is placed in the load library calls). Now as I don't have access to Windows source code I cannot say for certain that this is the case but I can infer this from how I have seen Windows behave in past cases.

So if an incorrect versions of one of our dlls, our dependencies or the dependencies dependencies are being loaded from somewhere else, putting our path in the system path will fix that issue, however any other application that relies on a different version of the shared dependency may start running into problems.

Trevor

[Former Member · Accepted solution]

That solved the problem!!! Adding that path to the PATH variable!

Very THANK YOU!!!

[Former Member · Accepted solution]

Good idea man 😛

I solved same problem,

labour in vain

My dev: OS vista Ultimate, VS 2008 (w AjAX, Silverlight), Oracle EBS 12 (SQl 2008)

My server: 2003 Std SP2

Thank you everybody. Special Jonathan Heller

[Former Member · Accepted solution]

Hi,

I'm not sure to understand the solution wrote by Jonathan Heller. Please can someone can give me more details how to fix this issue.

Thanks

[Former Member · Accepted solution]

Ok. I have the same problem and it looks like "solution"

Thanks Jono. You made a great contribution to this thread.

You folks from SAP...is this the official solution? Should I advise my customers to put the path into their env.?