Why printer properties change in Access reports when appl is run from different pc?

[jkostrzewski]

Can anybody solve this problem?

ENVIRONMENT:
Application is built in MS Access 2007. Data are stored on SQL Server while users run compiled Access projects. User PCs run Windows XP and Windows 7 utilizing Access Runtime (no access installed on client PCs). Some reports use specific paper sizes and are printed from designated printers through printer server.

PROBLEM:
On developer's PC reports see non default printers properly and application works fine. When the application is compiled and copied onto users PCs the same reports do not use designated printers and if they do see them then the paper sizes are incorrect, as if chosen randomly. It looks to me that the report design itself stores not the names of the printers (nor the names of the paper sizes) but instead their codes as recorded on developer's PC. It means that all PCs, even if have the same printers installed from the access application are seen as completely different codes.

Is there any cure to this obnoxious problem?

Thank you.

[NeoPa]

I think this is about the printers available on the various PCs. If the same printer isn't available on a destination PC as the report was designed for then it tries to approximate and has difficulties.

[jkostrzewski]

The same printers are set up on all PCs, including the same names and pointing to the same printer server.

[jkostrzewski]

Maybe I should add that when the application is compiled on the Windows XP machine and report uses networked printer all seem to work fine.

HOWEVER: When application is compiled on Windows XP machine and printing is done as "direct" to IP address of the printer it is again all messed up!

Very weird.

[NeoPa]

Why is that weird? Surely that is the behaviour you'd expect.

It's hardly likely to recognise printers as the same if you only refer to them via IP address. Just another reason not to use that approach (which isn't a very clever approach anyway I would have thought). Network based printer servers are not just for decoration ;-)

[jkostrzewski]

Maybe I did not express myself properly. Imagine you install a printer on one PC using direct IP access, which is static. You set up its properties including default page size, default feeder type etc. Next, you install the same printer on another PC using exactly the same name and properties. How come is that approach HARDLY likely to recognize those printers by application? Why should I expect different behavior? Am I missing something? Both PCs see exactly the same printer with exactly the same settings, so how come Access Report messes it up? Maybe it was not the best approach but to me it seemed to be quite logical.

Nevertheless, I had to abandon this aproach and move to everybody's favorite network printer because it solved this weird, i repeat weird problem. So, for some time, when our network was purely Win XP all worked fine. Now, with Windows 7 as my developer's machine I face the same problem anew, even though printing is done through holy server. So, is there a solution to that or not? How can you explain the situation that when I open the report on my machine it works fine but when the same report is opened on another it is all messed up? Is this really a behavior I should expect? How can I ensure that report design in MS Access remembers exactly what printer and on what kind of page should it print? Only if I install the full Access on user's machine and re-compile the application on that computer it works fine. But only on that machine.

[NeoPa]

jkostrzewski:
How come is that approach HARDLY likely to recognize those printers by application?

Because each printer set up on each machine is different from all the rest. Instead of using a unified consistent reference you're using separate references to similar printers (It neither knows nor cares that each printer is actually the same physical device).

I suppose what is expected by one person with one set of experience is not necessarily obvious to another person with different experience. It's hard for me to tell what is standard, as I only really know my own experience. I wouldn't have been surprised by what you describe in those circumstances, but I possibly have a different background in Windows and networks from you. I was a network administrator for many years.

What you need to understand though, is that printers set up separately to print to IP ports are still, internally, local printers on that machine. Network printers, on the other hand, those provided by a network server, can be understood as pointing to the same printer, which is essentially a logical printer provided by the printer server. It may help to understand if you try pausing a printer set up to print to an IP port. If you pause it on PC A then PC B is not paused. It has a separate printer and local queue. An administrator can properly manage a networked printer though. Pausing the queue from PC A, because it is a central queue, also effects PC B.

[jkostrzewski]

Thank you for your explanation about printers. I do understand it but that is not the problem of my original post. It is not about administering printers or nuances between IP printing and server printing. It is about how to set up an Access Report's printer properties so that they stay the same on each PC.

As I said at the beginning the applications we use print those specialized reports through printer server. When application is compiled on Windows XP then all PCs print properly, i.e. to the correct printer and with correct paper size. However, when I compile the application on Windows 7 then the paper size is different on different machines. Depending on the machine, user can see the preview with different page layout and correct it but on another PC the Access just gives an error that print job was cancelled and nothing can be done. I suspect that in that second case application still sees that same networked printer but for some reason the paper size is chosen incorrectly and that prompts Access to cancel it.

This has nothing to do with IP printing now. Historically we used IP printing before and everything worked fine until we started using those different special kind of papers, so some reports had to be set up to print to non-default printers. At that point it all got messed up and only solution I could figure out was to use print server. All went well for some time but once I upgraded my PC to Win 7 and compiled applications on it, the problem appeared again. To be precise, I think now that what is messed up is not the printer but rather paper size and feeder type. Those are properties which you set up in Access report when designing it to print to specialized printer. Printer itself has those same properties set up as default so all seem to be OK, however after compiling the application and copying it to another PC the report in question messes up those properties.

So, how can I ensure that my applications print consistently regardless of the PC they are run on? Maybe instead of using standard MS Access report design and VBA underneath I should dig into OS APIs to work out those printers? How other Access developers handle this kind of printing?

[NeoPa]

I'm afraid I am near the limit of my understanding of printers here and how they work in Access Reports. Let me explain what I can at least, but it may not be enough to resolve your problem.

1. Access reports are designed with a specific printer. They are always dependent on properties of the printer they were designed to print to.
2. From what you say I would infer that how printer devices (in the OS, and by extension in Access) are maintained in Win 7 is different from how they are in Win XP. This is very probably at the heart of your problem.
3. Page sizes etc are properties of the stationery, but the stationery is a property of the printer. I don't believe you can rely on stationery on one printer necessarily mirroring that same stationery on another. Other settings such as printable border edges are certainly dependent on the specific printer of course.
4. Some better news is that I know most, if not all (I suspect all), of the properties for a printer are available via the VBA class structure (IE. No need to venture into OS calls). I have some experience of that but from a long while back and I have no notes available now.

I know printers in reports can be very strange, and it can be hard to realise why it has to be so complicated (I don't know enough to know exactly why it should be so, but enough to realise it could never be as straightforward as most people seem to expect), but it's not an area I do much with I'm afraid. Most of my reporting was to standard network printers and I'd set the whole network up for maximum compatibility anyway (It seems Windows OSes were more compatible up to Win XP than they have been since). As time went by though, I found most of my newer reporting was via export into Excel.

[jkostrzewski]

Thank you for your insights.

For so many years of my experience with IT I was always wondering why such basic device as printer has to have so many problems. If you look through the history of IT there always were problems with printers, at least on the application level.

It looks to me that when you install a printer on a client machine all its properties are enumerated and stored in registry along user friendly names. Name of the printer as well as other properties have codes through which they are recognized by the OS. Each machine can have completely different codes, so when Access Report is being opened it refers to the codes instead of the names and hence the mess-up. I guess that I will have to go to the level of those codes and hopefully as you suggested in p.4 use VBA class structure to access them.

[NeoPa]

jkostrzewski:
For so many years of my experience with IT I was always wondering why such basic device as printer has to have so many problems.

You want to try configuring them! Nothing was ever as straightforward as I was expecting.

I regret that I wasn't able to provide more help, but I wish you luck handling the rest of this. If you get stuck with some of the properties or objects then post again. A separate thread if it's not really the same subject (I suspect it won't be), but you can link to this one if you feel it may make it clearer.

One tip on searching for properties and navigating through class paths is to use the Object Browser facility (Found by pressing F2).