Access + Windows Printer/Port names

  • Thread starter Thread starter Guy Hocking
  • Start date Start date
G

Guy Hocking

Hello there,

We have a corporate database written in Access, the frontend clients use
Access 2000 and XP, the backend uses Access XP.

The problem i am encountering is as follows -

Upon writing reports and assigning specific printer/s settings to these
reports, we are struggling to implement a "universal" printer naming
convention available accross ALL windows platforms.
There are 2 developers (one being myself), we both have Windows 2000 and XP
on our machines and would like to use them to develop this database.
However, the majority of clients are Win9x with around 20% being XP/2000.
When developing a report and assigning the printer setting to print to IE-
//SERVER01/PRINTER1 on Letterhead - doing this in win2000 produces different
results than doing this in Win98, as the printer and port settings are
different names/naming conventions in different OSs.

This is a big problem as only the OS the report was setup in can print the
report.... all the other clients get an error message stating the printer
cannot be found. When infact the printer IS setup, but the port and device
are a different name in this OS.

I hope you understand what i am getting at.

I was wondering if there is any way that Access can simply look for only a
printer name, or a selection of printers defined in Access universally. I
cannot understand why Access cannot pickup on the same printer in different
OSs, even tho the names and port names are different (because of the
different versions of Windows)!!

I have waffled on a bit and perhaps made myself unclear...... If anyone
needs more/less info let me know....

Eagerly awaiting your help

Guy Hocking
IT Consultant
BF.com
 
Now why would you include externaldata and replication in your list of
newsgroups? Replication is *NOT* recommended for objects other than
tables and records.
Upon writing reports and assigning specific printer/s settings to these
reports, we are struggling to implement a "universal" printer naming
convention available accross ALL windows platforms.
There are 2 developers (one being myself), we both have Windows 2000 and XP
on our machines and would like to use them to develop this database.
However, the majority of clients are Win9x with around 20% being XP/2000.
When developing a report and assigning the printer setting to print to IE-
//SERVER01/PRINTER1 on Letterhead - doing this in win2000 produces different
results than doing this in Win98, as the printer and port settings are
different names/naming conventions in different OSs.

This is a big problem as only the OS the report was setup in can print the
report.... all the other clients get an error message stating the printer
cannot be found. When infact the printer IS setup, but the port and device
are a different name in this OS.

I hope you understand what i am getting at.

I was wondering if there is any way that Access can simply look for only a
printer name, or a selection of printers defined in Access universally. I
cannot understand why Access cannot pickup on the same printer in different
OSs, even tho the names and port names are different (because of the
different versions of Windows)!!

I have waffled on a bit and perhaps made myself unclear...... If anyone
needs more/less info let me know....
Click to expand...

Excellent question and description of your problem. As I never
assign reports in this fashion I haven;t some across this problem
myself.

Others may have a better solution to your problem however some
workarounds are as follows.

1) If you are shipping an MDB you can use the PrtDevMode logic to
assign the printer names and ports at print time. Which is what I'd
prefer to do in any event given that Network Nazi's, err Admins, can
change things without notice. This way users can change the settings
themselves. Or at least designated power users.

Note that using PrtDevMode requires that you open the report in design
mode. Which can't be done in an MDE. You can use Automation to open
a reports MDB and manipulate it there. But that gets a bit trickier.

2) Make a different version of your FE available to Win9X users vs
Win XP/2000 users. Before you make a new version of your FE
available to your users go to a Win9x machine and change the printer
settings as required. This will work for MDEs of course.

You can automate this process by using PrtDevMode and writing some VBA
code. In the code you would open the reports in design view

You can make life easier by using the Auto FE Updater utility to
automatically distribute changes to your users. See below for more
info.

3) If you hadn't stated "Letterhead" I'd've suggested just changing
the default printer on the fly.

You can change the default printer using updates to the INI file and
some sample code. See DefaultPRT.ZIP at
http://www.mcwtech.com/downloads.htm

=================

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the utillity see
the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server. Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.

===================

ACC: How to Change a Report's Printer Using Code Q129397
For more information about PrtDevMode and PrtDevNames, search for
"PrtDevMode property" or "PrtDevNames property," using the Microsoft
Access 97 Help Index or please see the following web site:
http://www.microsoft.com/AccessDev/Articles/GetzCh10.HTM

For more info on some restrictions, such as not being able to open a
report in design mode in MDEs, do a search on prtdevmode at the
Knowledge Base at support.microsoft.com.

Also note that this is very complex code and is recommended only for
advanced programmers. Also the above chapter was taken, IIRC, from
the Access 95 Developers Handbook. If you have a newer version of
the Developers Handbook it may be better documented.
www.developershandbook.com

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Back
Top