


However, as crtslv.dll is a COM-registrable DLL, in theory it can have any name and can be located anywehre, since it's registered correctly on Windows Registry, as well as ExportModeller.dll. Equally, tslv.dll is the name used by CR 8.0, whereas crtslv.dll is the name used by CR 8.5. Crystal Reports 8.0 will only recognize the PDF exporting DLL if you use the u2fPDF name convention, but Crystal Reports 8.5 started using the crxf_pdf name convention. Knowing what I have to add to my InstallShield file so that theĮxactly. This fix works for my development machine, but it's pretty painful forįixing client machines that only get the runtime components. But the file timestamps are identical and IĬouldn't identify a registry entry that explains it. "DBEXDRVRWIN_EN_200401.EXE" onto a machine that the problem goes away Iįound that when I install the monthly hot fix file I have painfully discovered a process that corrects the problem. Seem to be computers that have previously contained Crystal ReportsĨ.5 runtime components on them, but not 8.5 itself. It fails on some machines, but not on others. PDF export works fine before applying SP3. CAB files), like i6comp, that you can get here (or somewhere else): Tip: Instead of installing the SP, you can unpack ' cr85win_en_sp3.exe' and after that use some tool to decompress ' data1.cab' (it's a Install Shield v6 Compressed File, not compatible with Microsoft.

Googleing for "crystal reports 8.5 service pack" I found a link to the CR 8.5 SP3 on a brazilian website ( ).

I replaced the 'craxdrt.dll' file and the problem was solved: In another application I use the RDC component and was experiencing the same problem. ' ExportModeller.dll' v 8.6.2.440 (%ProgramFiles%\Seagate Software\Shared) (or %CommonProgramFiles%\Crystal Decisions\2.0\bin ?)īut after some testing I finally concluded that the file that solved the problem was the main API dll, ' crpe32.dll'!! I use the Automation Server, that uses the 'crpe32.dll' file, so in my case this one solved the problem:
