Code to change DYMO printer

Posted on 2014-09-07
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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 6
  • 6
LVL 84
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 84
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.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


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 84
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 84
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 84
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) 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 84

Accepted Solution

Scott McDaniel (Microsoft Access MVP - EE MVE ) earned 500 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

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

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

Suggested Solutions

Since upgrading to Office 2013 or higher installing the Smart Indenter addin will fail. This article will explain how to install it so it will work regardless of the Office version installed.
In Part II of this series, I will discuss how to identify all open instances of Excel and enumerate the workbooks, spreadsheets, and named ranges within each of those instances.
This video shows where to find the word count, how to display it, and what it breaks down to in Microsoft Word.
The viewer will learn how to use the =DISCRINV command to create a discrete random variable, use this command to model a set of probabilities and outcomes in a Monte Carlo simulation, and learn how to find the standard deviation of a set of probabil…

733 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