Varying output from acFormatTXT

[cat_herder]

I have an Access2000 database that is accessed by multiple users from their
workstations. All users are licensed and "supposedly" using the same
release of Access2003. When generated, a report is saved to the same
directory, regardless of the user, in a sub-folder below the one in which the
..mdb resides.

When previewed, the report is the same on each of the users machines.
However when "DoCmd.OutputTo acReport, stDocName, acFormatTXT,
Application.CurrentProject.Path & "\Reports\" & stFileName" is used to save
the report to file, the header is formatted in at least three differing ways,
apparently by something residing on the user's machine.
What is the specific cause?

 

[Dirk Goldgar]

I have an Access2000 database that is accessed by multiple users from
their workstations. All users are licensed and "supposedly" using
the same release of Access2003. When generated, a report is saved
to the same directory, regardless of the user, in a sub-folder below
the one in which the .mdb resides.

When previewed, the report is the same on each of the users machines.
However when "DoCmd.OutputTo acReport, stDocName, acFormatTXT,
Application.CurrentProject.Path & "\Reports\" & stFileName" is used
to save the report to file, the header is formatted in at least three
differing ways, apparently by something residing on the user's
machine.
What is the specific cause?

My guess would be the printer drivers. Is this report set up to print
to the default printer? If so, this would likely vary from PC to PC.
If the report is always output to text, maybe the differences would
disappear if you set it to print to the "Generic / Text Only" printer.

 

[cat_herder]

The application does not print the report. It simply saves it as a .txt
file. When the .mdb file is copied to other machines and the process is
repeated exactly, the output has at least three variations.

One machine produces expected output.

A second machine splits one particular output line into two lines. This
was found to be due to sensitivity to a slight horizontal misalignment of
text boxes in the header design. But only a few machines seem sensitive to
this misalignment and produce this error. All work as expected if the text
boxes are perfectly aligned horizontally. (These machines also has the error
that follows)

The third truncates the rightmost character displayed in some header text
boxes. The design had 6 characters diplaying in a text box .5521 in wide.
This width works on some machines. On others it must be increased to a
minimum of .584 in. to avoid the truncation.

Why the difference between similarly configured machines. ( All are the
same manufacture and model, and have the same standard software
installed.... but a lot of "stuff" happens after these machines are
distributed to the users)

Thanks for your help. Your previous advice triggered some exploration that
helped.

 

[Dirk Goldgar]

The application does not print the report. It simply saves it as a
.txt file. When the .mdb file is copied to other machines and the
process is repeated exactly, the output has at least three variations.

One machine produces expected output.

A second machine splits one particular output line into two lines.
This was found to be due to sensitivity to a slight horizontal
misalignment of text boxes in the header design. But only a few
machines seem sensitive to this misalignment and produce this error.
All work as expected if the text boxes are perfectly aligned
horizontally. (These machines also has the error that follows)

The third truncates the rightmost character displayed in some header
text boxes. The design had 6 characters diplaying in a text box
.5521 in wide. This width works on some machines. On others it must
be increased to a minimum of .584 in. to avoid the truncation.

Why the difference between similarly configured machines. ( All are
the same manufacture and model, and have the same standard software
installed.... but a lot of "stuff" happens after these machines are
distributed to the users)

Thanks for your help. Your previous advice triggered some
exploration that helped.

As I understand it, it doesn't really matter that you don't actually
print the report, but only output it to text. Access uses the printer
driver to format the report, and that has an impact even if you then
output the report to a text file. Did you try designing the report for
the "Generic / Text Only" printer? Also, as I recall, the exact sizes
of text boxes has an impact. It's been a while since I twiddled with
this, though, so I can't give you specific advice. I think maybe
controls should be set for a height of 0.125", and you should use a
fixed-pitch font like Courier (or Courier New), and you should have no
vertical space between lines. But that's just from memory.

An alternative to all this report-tweaking is to use code write the
output data directly as a text file, using basic I/O statements, thus
bypassing the reporting engine completely.

 

[cat_herder]

Thanks Dirk! The printer driver influence makes perfect sense. I played
around with the text box length and found that using .01027 in./character to
calculate the minimum required text box width works for all machines
involved. I'm certain the same logic will apply to line height as well.

Thanks for the help.