This one is going to be mid-rant because I can't even find anyone else that has hinted at having this problem...arggghhh!
The problem:
The current problem is when a couple of my reports print, they want to print 5,572 pages which is about 5,568 too many!
I've got some pretty complex reports in some legacy packages that I support, i.e. I didn't write it, I just need to keep it running and add onto it.
The reports look fine great, but at the top of the report is a button with the text: "Printable Version". When the report is created, a PDF is created following code that I've found many many places on the web, for instance:
// Export the report to a PDF for printing
CrystalDecisions.Shared.DiskFileDestinationOptions DiskOpts;
DiskOpts = new CrystalDecisions.Shared.DiskFileDestinationOptions();
oRpt.ExportOptions.ExportFormatType = CrystalDecisions.Shared.ExportFormatType.PortableDocFormat;
// Choose a name for the file that is unique to the session
// If you do not specify the exact path here (i.e. including
// the drive and Directory),
// then you would find your output file landing up in the
// c:\WinNT\System32 directory - atleast in case of a
// Windows 2000 System
DiskOpts.DiskFileName = getPDFFileName();
// The Reports Export Options does not have a filename property
// that can be directly set. Instead, you will have to use
// the DiskFileDestinationOptions object and set its DiskFileName
// property to the file name (including the path) of your choice.
// Then you would set the Report Export Options
// DestinationOptions property to point to the
// DiskFileDestinationOption object.
oRpt.ExportOptions.DestinationOptions = DiskOpts;
// Export the file.
oRpt.Export();
Then when the button is pressed, I do this:
// The following code writes the saved PDF file to the browser
Response.ClearContent();
Response.ClearHeaders();
Response.ContentType = "application/pdf";
Response.WriteFile(getPDFFileName());
Response.Flush();
Response.Close();
// Now we delete it
System.IO.File.Delete(getPDFFileName());
Things I've tried:
- I'm loading ALL Crystal Reports assemblies local so that I know for sure, for sure that I am loading the ones I want
- I've checked to make sure, just in case, that the Crystal Reports assemblies I want are in the GAC on the server
- I've inserted extra characters and footer sections on the sections that it seems to insert the extra lines on
- I've swapped the above code out for code that streams the report instead of producing the PDF all the time since some of the "Delete" code never really deletes, and nobody cleans up after this thing on the server
- I didn't mention it, but this code is .NET 1.1 -- I am in the process of porting it all to .NET 2.0 and have a .NET 2.0 version that runs at least as far as these reports, and it produces the EXACT SAME PROBLEM!
Note I said *some* of my reports. This is an upper-level assembly report showing workorders and exceptions for a build. Some PartNumber/Serial Number combinations produce great PDF files for printing and some don't... although ALL appear fine in the browser.
Workaround:
Yes I have a workaround... and that's always good to keep the customer happy.
My workaround is to install PrimoPDF Free, and remove the "View Printable Version" button. Give a little tutorial on File->Print and printing to PrimoPDF and booya, it's done.
I seriously doubt this will be accepted as a long-term solution, and who knows, this anal-retentive place may not even allow them to install PrimoPDF, but at this point, I'm out of ideas.
I have no problem hitting the client up for a software package, but at this point, the report is fine all I want to do is print what's on the browser to a PDF... so I really don't want to install iText or any of the other options I've looked at today and begin again with laying out the flipping report...
Options, thoughts, suggestions, contributions to my Crown Royal fund...
What's a nice Silverlight fanboy like me doing in a place like this???
Stay in the 'Light!