How do you link a specific printer to a Report and preserve that link if coding on a separate system? (1 Viewer)

[TOPSie]

I am supporting an established Access system for a distribution company.
They have a set of pre-printed labels and a corresponding set of label printers each loaded with a roll of their particular labels.
The Access system has a Report for each format of label. The Reports are programmed with extra information (e.g. best before date) used to overprint the standard label.
The printers are all on the local network and appear to be addressed by their IP address (e.g. 192.168.40.93) where the last triple is different for each printer.
However I can find nowhere in the Access.mdb file – properties or code where these connections are defined.
The only way I can see these addresses is when I take a copy of the mdb file and import it to my development system, which is not on the users network.
If I then attempt to open one of the reports in design view the following message pops up:-
"This document was previously formatted for printer 15PACK on 192.168.40.93. but this printer is not available. Do you want to use the default printer"
I don’t want to OK this as it would mean that if I copy the mdb file back to the users network the print association is lost.
If I choose Setup… and then the Page tab:- Allows me to choose a printer - but as I am not on the live network this is pointless
If you view the Properties of the report or search the code there is no mention anywhere of the printer connection details.
On the “live” system, nothing in the Report details gives any indication of the printer connection. I can’t even find the Page Setup dialogue.

Where does Access store the printer association and how can I change it - or at least preserve the live setting whilst doing offline development?

 

[jdraw]

You may get some insight from the first item in the Similar Threads at the bottom of this page.

 

[Minty]

I have struggled with exactly this scenario for a long time.
Unfortunately, I have never found a good solution, particularly with different labels and printers on one site.

Recently, I persuaded a client to send me a label printer so I could set it all up locally, do a load of screenshots of the printer settings, save it all and take a load of back up copies, then ship him the printer back and email him a copy of the working database.

They haven't come back to me yet, but I have allocated at least an hour of time to have to remote in and set it up again. Massive PITA.

 

[TOPSie]

Thanks for the "Similar" list. The first one refers to a Microsoft article - which it seems that the original developer used. The issue I have is that in order to establish a relationship between a report and a specific printer it appears that you must do this connection on the Live system. But in these days of lockdown I must do all my maintenance remotely. If I take away the .mdb file and change it I am in danger of removing the printer association and hence screwing up the application. On my (remote) system, I cannot open the report (in design mode) to update it without a printer association

 

[gemma-the-husky]

[edit. I keep revising this slightly. I think you want the application.printers collection]

First, you can hard code the printer queue you want in a report but you can also set a different printer at runtime, to either change the default printer or to change the hardwired printer.
Note that named printer queues are case sensitive.

Now, if you print on another printer, you have to temporarily set the different printer as the default printer in access (application.printer), and after the print is completed, set the printer back to nothing, to return to the default windows printer.

Again, you get problems with the text case of a printer name - so the best thing is rather than try to get the printer name spot on, instead iterate all the printers, and find a match (or enough of a partial match). You can even iterate the printers, and give the user a choice within your dbs =,eg in a combobox. So if you have labelprinter1 on 192.168.xxx.xxx and labelprinter2 on 192.168.xxx.xxx you and you are looking for just "labelprinter" it will be easy to let the user pick the printer he wants from either all the printers, or just the labelprinters

dim ptr as printer
for each ptr in application.printers
     if ptr.name = desiredprinter  then 'this test is NOT case sensitive
         'note you can do an instr test, to pick up a printer queue something like yourprintername on whatever
         set application.printer =  ptr  'this does it!
        'leave loop
    end if
next
'need code here in case no match found.

then AFTER the print is completed simply

set application.printer =  nothing  'to reset to the windows default.

hope this helps, if this resembles the problems noted above.

In a distributed system, you would probably want system settings the user could use to designate the IP address of whichever labelprinter they want as the "desiredprinter" for a given label type. Then its all under the user's control, and you shouldn't have to worry about it.

Obviously you can test it by having your own labelprinter with whatever name you care to use.

 

[theDBguy]

On my (remote) system, I cannot open the report (in design mode) to update it without a printer association

Hi. I'm not sure if this will work/help, but have you tried installing the printer driver on your system even if you don't have the physical driver attached to it? Just a thought...

 

[bastanu]

Have you tried to create a table and store the production ReportName\PrtDevNames for each report?

Reports: Change printers from code

Cheers,
Vlad

 

[TOPSie]

This is helping guys. I think I can now answer one of my questions. The printers "seen" by the application are stored in the Application.Printers collection. Presumably this collection is instantiated at load time by Access interrogating the (Windows) system for a list of printers.
So of course this list is different if you run up the application on a different system.
So another piece of the jigsaw in place - but still a few more to slot in

 

[bastanu]

Here is some more info:

The Printers Collection and Printer Object | Database Solutions for Microsoft Access | databasedev.co.uk

The Printers Collection and Printer Object: The printer object is part of the overall Access Objects and is contained within the printers collection. The Printers collection of the Application object contains a collection of Printer objects that represent all of the printers installed on a...

www.databasedev.co.uk

Cheers,

 

[sxschech]

This is probably an extra couple of steps since it would have to be sent to the printer after the fact.

Haven't actually tried it, just thinking...

What if instead, set the default printer to PDF that way, presumably, regardless of what printers are available, the prompt or reformatting issue by choosing another printer may not come up.

 

[gemma-the-husky]

This is helping guys. I think I can now answer one of my questions. The printers "seen" by the application are stored in the Application.Printers collection. Presumably this collection is instantiated at load time by Access interrogating the (Windows) system for a list of printers.
So of course this list is different if you run up the application on a different system.
So another piece of the jigsaw in place - but still a few more to slot in

I don't think so. I think the application.printers collection is most likely a "mirror" of the actual windows printer collection, just in a format made available to Access. I imagine if you set up a new printer, you wouldn't need to close and re-open access.

This is why the collection is case sensitive.

If you said
set activeprinter = application.printer("epson123"), and the printer was called "Epson123" the action would fail.
That's why it's easier to iterate the printers until you find one with the name ="epson123", because this comparison is NOT case sensitive. This way you also find printers with a partial name of "Epson123" - "Epson123 on Server4"

There is no way the developer can know what printers the user has. What you really want is to give him an easy way to pair the printer he wants to use with a given report

I do use this so, eg, a head office can send the same report directly to the correct printer at a given sub-office. It knows from the sub-office record which printer to look for, and directs the same single report to the appropriate printer for the selected sub-office.

 

[Minty]

Cheers Dave - I think that may help me in the future.
The current clients situation is complicated by the fact they want tp change label sizes on one printer - as they don't use one size very often.
As a result, they will need to actually select the printer stock manually, as I don't think I can do that in code, even though I've stored the correct sizes with the label report.

I love lebels !