print to a specific printer in Access 2000

[Todd Stephens]

I am new to application development, and I have been tasked to create an
Access application to facilitate ordering of printed materials in my
company. The application will be used by our marketing managers who are
dispersed throughout the company (multiple physical locations). I will be
placing the application on a server accessable to all via the WAN.
Eventually this will be migrated to a SQL backend with a web interface, but
that is not possible at this time.

The problem I am running into is getting a job spec sheet (a report) to
print on a printer located in the company's in-house print shop. I have a
command button set up to print this report once the user is done filling out
the order information on a form, but I cannot figure out how to get the
report to print to a specific printer rather than the current user's default
printer. It looks like Access 2002 would make this a simple matter with the
printers class, but I am limited to the 2000 version. The printer I need
the report to go to is networked, so connectivity is not a problem. Is this
even possible in 2000? If so, how do I go about coding this in? Thanks in
advance for any help.

 

[Todd Stephens]

If the printer is a network printer and the IT staff has done its job
properly and installed it with the same device name on each workstation, it
is a simple matter of opening the report in Design View and choosing that
printer then saving the report. It will then always print to that printer.
--

I have come to the conclusion that if I am to continue with this particular
line of thought, I am going to have to persuade the project requestor to
have the users set up this particular printer on their workstations. I
would like to have the printing of the report completely automated so the
users don't have to manually select it each time, but that does not look
like a possibility. It is not practical for the users to have this printer
set as their default printer, so automated printing does not look likely.
The printer idea may need to be abandoned.

I am also looking at having an email automatically sent to certain support
personnel in the printing department whenever a new job request is entered
in the database and just have them print the specs themselves. This may be
the best solution for the constraints I have at this time.

On the bright side, I will certainly come out of this with a greater
understanding of distributed application development and a broadened skill
set. I also like the idea of having the users just have a front-end on
their machines with a centrally-located back-end. This was the direction I
was going for the printing side, but it makes sense to do it for the
customer-users as well. Thanks for your suggestions.

 

[Albert D. Kallal]

I have come to the conclusion that if I am to continue with this particular
line of thought, I am going to have to persuade the project requestor to
have the users set up this particular printer on their workstations.

What part of the above did you not get? If you follow the above
instructions, then the report WILL ALWAYS go to the printer that is set for
the report, and it will COMPLETE IGNORE THE USERS default setting. Did you
bother to even try the above suggestion? I will quote:
printer.

As mentioned, the only problem with the above is that the IT department has
to make sure that EACH PC has the EXACT same printer name. Of course, if you
want to switch printers in code, you would also have to ensure that EACH PC
has the exact same printer name. This printer certainly DOES NOT have to be
the default printer, but it must be exactly the same name on each pc.

In my experience, I can't recall seeing a company that has the exact same
printer name from computer to computer. In fact, you especially run into
trouble when using differing versions of windows (win9x to win2000/xp is
great example). Since the printer drivers are often different for
win2000/xp, then again the printer name is different. So, in mixed
environments, again, the printer name from computer to computer is not the
same. Note that you need the same printer name if you started switching to
the printer via code also.

So, to be clear, you can save a SPECIFIED PRINTER with a report, and it will
thus IGNORE the users default printer.

However, since the printer name OFTEN varies *slightly* from computer to
computer, then the above is not the best from a distribution point of view.

I thus usually build a table with each users default, and LET THE USER
select that printer, and then use code to switch printers. Even with the
a2002 printer object, that slight change of the printer name from computer
to computer is a problem. As mentioned, if your IT department is a real
straight arrow, then all your pc may have the exact same printer name that
can be used (we are talking about a non default printer here).

You can grab my short printer change example code at:

However, you still have to address the problem of this printer name being
different from computer to computer. (and I do that by given a user a option
to select the printer for reports, or special things like invoice printers).

 

[Albert D. Kallal]

Opps, that link to my short printer switch code is:

http://www.attcanada.net/~kallal.msn/msaccess/msaccess.html

 

[Todd Stephens]

What part of the above did you not get? If you follow the above
instructions, then the report WILL ALWAYS go to the printer that is set for
the report, and it will COMPLETE IGNORE THE USERS default setting. Did you
bother to even try the above suggestion? I will quote:

Well, since it is Sunday and I'm not at the office, no I did not try the
suggestion out. I've done this with reports before; my intent was to not
have the end users need to install this printer on their workstations as the
point of the project is to make life as simple for them as possible. The
problem really lies in convincing people in multiple departments in numerous
geographic areas to install this printer on their workstations. Easier said
than done. Assuming I can get them all to do it, then getting them to name
it the same thing is not a problem either.