Exporting same report twice with identical results
Hi,
I have a requirement to Export a Report Builder report to a format that
produces the same result each time (for the same given data) such that an
MD5 can be calculated of the output file.
I currently have a solution that works on most machines, but some laptops
(with widescreen resolution) produce inconsistent results. I run my report
and then export it to the "dtReportTextFile" format. It would seem this
format tries the represent the report in text format as close as possible.
So if a column is truncated, then that will be shown in the exported file.
What we have found is that on some widescreen laptops, some columns are
wider (or narrower) than the same columns run on a standard aspect ratio
machine (1024 x 768; 800 x 600 etc...)
Question is, is the a format I can use that will produce identical results
every time for the same given data regardless of the machine that it is run
on?
Cheers.
I have a requirement to Export a Report Builder report to a format that
produces the same result each time (for the same given data) such that an
MD5 can be calculated of the output file.
I currently have a solution that works on most machines, but some laptops
(with widescreen resolution) produce inconsistent results. I run my report
and then export it to the "dtReportTextFile" format. It would seem this
format tries the represent the report in text format as close as possible.
So if a column is truncated, then that will be shown in the exported file.
What we have found is that on some widescreen laptops, some columns are
wider (or narrower) than the same columns run on a standard aspect ratio
machine (1024 x 768; 800 x 600 etc...)
Question is, is the a format I can use that will produce identical results
every time for the same given data regardless of the machine that it is run
on?
Cheers.
This discussion has been closed.
Comments
When exporting to a text file, ReportBuilder tries to translate the text
position of each text component on your report to a standard text grid
(similar to a dot matrix printer). This can look different between the
screen and printer and between separate printers, however it should be
identical between different monitors. Though the aspect ratio can be
different for each monitor, I believe the pixels per inch is the same (96
ppi), unless you are using the large size.
I did a quick test exporting a simple two column report on my 1600x1200
resolution monitor, then exporting the same report with my 1920x1200
widescreen laptop. The space between each column was identical.
How are you viewing these text files? Are you certain the number of spaces
between the columns are different between each machine? Are you sure the
fonts being used are the same?
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
If I run the report to screen (attached - JPG) I get different results than
I do when exporting the file to "dtReportTextFile" (also attached - txt).
Hopefully the attachments make it through and you can see that when printing
to the text file a whole row is missed out (the row starting "Audio Cards").
I had originally hoped to use the Report Archive Format, but it embeds the
Report Primt Date in the file. If you could tell me a way to stop it doing
that I may be onto a winner, or even throw some light on why a row is
missing on the first page of my report. Other lines are missing too, just
thought I'd show the header to demonstrate the problem.
Cheers.
For future reference, please send all attachments to
support@digital-metaphors.com.
Remember that when exporting to text, you need to be sure the text objects
on your report are measured to fit on a text grid. If items are too crowded
(as they look in the jpg you sent) you will start to loose data to fit the
rest. The following article gives hints on how to print to a Dot matrix
printer... the same rules apply to exporting to a text file.
Have you thought about trying to export to PDF?
-----------------------------------------------
Article: Printing to Dot Matrix Printers
-----------------------------------------------
Dot matrix printers are natively line and character based. Most dot matrix
printers can emulate graphical (i.e. pixel based) printing, but there is
additional overhead which degrades printing speed.
Some options for maximizing performance:
1. Use native printer fonts.
Each dot matrix printer normally has some built-in fonts. You can choose
these fonts when using the ReportBuilder Report Designer. Choose File |
PageSetup and select the dot matrix printer (or optionally use the object
inspector to set Report.Printersetup.PrinterName). The fonts displayed in
Report Designer's font drop down list located on the format toolbar will
display the printer native fonts (indicated by a special printer icon next
to the font name).
2. Vertically position and size objects in 1/6 inch increments.
A standard dot matrix printer can print 66 lines per 11 inch portrait page.
This translates to a line height of 1/6 inch. Therefore the height of each
band should be a multiple of 1/6 as should the size of the margins, the
vertical position of each object etc.
Tip: When designing the report, use the PrinterSetup property to specify a
printer that contains 600 dpi. Then set Report.Units to PrinterPixels. Now
100 pixes = 1/6 of inch when specifying the positions of objects in the
layout.
3. Keep the layout simple, avoid using graphics of any kind.
Alternatives to using the dot matrix printer driver:
1. Use the generic text printer driver.
When using the generic text printer you will need to use the courier or
courier new font and apply the layout techniques described above.
2. Use ReportBuilder's ReportTextFile device output format.
This ReportTextFile device can exports the report to a .txt file which you
can then send to the printer. Demo dm0107.pas in the main reports demo app
shows an example of printing a report to a .txt file and previewing the
results.
--
Regards,
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
Thanks for your reply. I can see what you're saying and it would certainly
appear that without a report redesign, it would not be possible to export my
report successfully in the format I have chosen.
I think we've solved the issue anyhow by using comma separated text output
and calculating the MD5 on that output, as it it turns out that the customer
does not actually need to read the reports.
FYI, I did try PDF and Archive format as they gave great representation of
the outputed report, however they both suffer from the same problem and that
is they both embed the Print Date in the binary stream and therefore are
unsuitable for producing consistent results on the same data over time for
an MD5 check.
Cheers.