Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


Code to change DYMO printer

Posted on 2014-09-07
Medium Priority
Last Modified: 2014-09-08
I see "Beehilly" was struggling with this, but it did not look like it got resolved.

For my Accde on the server... User swapping a DYMO printer might change the Printer Name (Eg.  "Dymo 400" to "Dymo 400 Turbo"  and when this happens my Accde on the server can not resolve how to change this for 3 reports I have.

I've tried combinations of this....  w/o luck.    Any ideas?

  DoCmd.OpenReport ReportName, View:=acDesign, WindowMode:=acHidden
  Dim prt As Object
  Set prt = Application.Printer
  Application.Printer = Printers(UseThisPrinterName)      ' (e.g. "DYMO Labelwriter 400 turbo")
  Set Reports(ReportName).Printer = Application.Printer  

I think something like this worked on Server 2003,  but now moved things to Server 2008 and no luck.

I sure appreciate any help.
Question by:FrankBabz
  • 6
  • 6
LVL 85
ID: 40309024
Your question is not in the right areas. You should always put Access questions in the Access zone specifically, and then in the Microsoft Office zone if appropriate.

The code you're using will work, but you must have the printer name EXACTLY right. If your user changes the printer name, your code would need to reflect that. You could cycle through all the Printers on the machine, using the Printers collection, and make sure the correct printer is installed when the application starts. If your code cannot find that printer, you could have the user select the correct printer, and then store that value in a table.

Author Comment

ID: 40309119
Hi Scott…   2 great tips today!

I have a table already that contains the name (e.g.” Dymo 400”) as the “driver” for which my 3 accde reports were created.  Having that info at hand… it should eliminate need to prompt user.

Only Dymo report names can start with “Dymo “ and that made it easy for me to collect them.
I can iterate the 3 reports to see if each one has the correct name/driver.

If yes… that’s great…. move on to next.

If no … can this be fixed?  (it is here where I am flailing and need help)

Unless the driver was uninstalled, it is there on the server, and I would like to replaces the wrong driver with the driver that belongs with the report (as my table dictates).

I mainly wonder in this case if just updating the table entry to new driver name would work most of the time (maybe)?  For example I doubt there are any layout differences between drivers for “Dymo 400” and “Dymo 400 Turbo.”

If all code fails, advise user that someone swapped Dymo device and original device needs reinstalled.  And/Or Accdb needs to rebuild 3 reports with new driver…  and new Accde…  and updated Table entry.  

Thanks in advance for your help….
LVL 85
ID: 40309501
I have a table already that contains the name (e.g.” Dymo 400”) as the “driver” for which my 3 accde reports were created.  Having that info at hand… it should eliminate need to prompt user.
So long as that name does not change, then you're good - just use code to pull that Printer name, and use code to set the name for that report. If the name does change, then your code would have to reflect that. Even if the name changes from "Dymo 4000" to "Dymo 400 T", you'd have to change that.

You could cycle through printer names and look for the one beginning with Dymo, if that makes sense. I don't think you'd need to rebuild, however. You don't have to open the report in Design view to set the Printer from code, so generally that means you don't have to recreate the accde file.
Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.


Author Comment

ID: 40310029
Thanks Scott...

Dealing with printers and drivers is tough for me.  To find shared Dymo printer installed on the Server....   Is that just a matter of searching the Printer collection?  If so, I can do that.   Yes... any Dymo printer would contain "DYMO " in the name.

My approach was to try and fix each Dymo report to insure proper driver during accde startup.  That would (I think) require opening each report in design view and saving the revised report.  Otherwise, how would I  "just use code to pull that Printer name, and use code to set the name for that report"   unless.....

Perhaps you are suggesting (instead of fixing during startup) to wait until the report is actually being run and then fix (if necessary) proper driver in the report Open event?   Any code snippets you may have would be most appreciated.
LVL 85
ID: 40310055
You cannot open the report in design view in an .accde file, if that's what you're asking, and trying to roll out fixes for specifics like that - i.e. UserA has a printer named "DYMO", but UserB has a Printer named "DYMO1" - would be quite frustrating, and prone to issues.

You can set the default printer just before you open the report:

Dim prt As Printer
Dim prtDefault As Printer

prtDefault = Application.Printer

For each prt in Application.Printers
  If prt.Name = "Your Printer Name" Then
    Application.Printer = Application.Printers(prt.Name)
    Exit For
  End If

'/ now open your report:
DoCmd.OpenReport blah blah
'/ reset the printer:
application.printer = prtDefault

Author Comment

ID: 40310185
Thanks again Scott...

I was on the path to use design view in the accde...   Thanks very much for saving me lots of time and future disappointment.

I presume I would only invoke your code if my Report Name included "Dymo " (per my convention restriction for all Dymo reports).   Now... I wonder if the report was originally designed to use "Dymo A" and Application.Printer sets "Dymo B" which printer will the Report be obliged to try to use?
LVL 85
ID: 40310378
I generally add a table that stores this sort of information - the ReportName, PrinterName, etc - then check that before I print each report. You could create a generic PrintReport function that accepted the ReportName (and other settings, like perhaps NumberofCopies, Orientation, etc) and then use that function to handle the printer change.

Also, be aware that you'd need to set your Report to use the default printer, store the current default printer, change the Application.Printer to the needed printer, and then change the Application.Printer back to that stored default printer. All this could be done in your PrintReport function.

Author Comment

ID: 40310498
I was thinking this might be what needed done (and hoping it would not be the answer)....

                         be aware that you'd need to set your Report to use the default printer

I will give that a try...  but I'm very apprehensive because  DYMO is tightly involved in the design and layout process... and it's not user friendly or nicely documented....  and I've never done a generic printer label before...  Especially worrisome is that my layout will be summoned to eventually work with the real driver.  

Any alternative thoughts?
LVL 85
ID: 40310517
I've worked with DYMO before, but never from Access. I've always done it through .NET, and it was fairly straight forward.

That said, setting your report to use the Default Printer is the norm in Access. You should only set a report to use a specific printer if you're certain that exact printer will be available, and you don't mind changing it when the printer is swapped out for a new one. Otherwise, you should always set Access reports to use the Default Printer (and that's the "default" in Access, to overuse the word):

Default Printer setting

Author Comment

ID: 40310931
This may not be the big a deal as I thought.  For my first label test all I did was change it to Default Printer.

FYI I had to modify your code a bit...

Set prtDefault = Application.Printer    (I needed to add SET)

prt.name is no longer supported...  you must instead choose prt.DeviceName or prt.DriverName

I used Device Name to find the Dymo device wanted.

more later....
LVL 85

Accepted Solution

Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 2000 total points
ID: 40310948
Sorry, I was using "air code" so you may find other issues like that as well ...

Author Closing Comment

ID: 40311136
Absolutely fantastic!!!

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In real business world data are crucial and sometimes data are shared among different information systems. Hence, an agreeable file transfer protocol need to be established.
Lost Word File? Eagerly, need it back? Read ahead; this File Recovery guide is for you.
The viewer will learn how to use a discrete random variable to simulate the return on an investment over a period of years, create a Monte Carlo simulation using the discrete random variable, and create a graph to represent the possible returns over…
Look below the covers at a subform control , and the form that is inside it. Explore properties and see how easy it is to aggregate, get statistics, and synchronize results for your data. A Microsoft Access subform is used to show relevant calcul…

578 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question