Share via

There was a problem retrieving printer information for this object. The object may have been sent to a printer that is unavailable.

Anonymous
2012-04-06T20:24:41+00:00

So, we just a couple days ago switched our copier service contract and upgraded from 2 Sharp copier/printer/scanners to 3 Konica-Minoltas.

Part of the process required installing the new Konica drivers off the network and then uninstalling the Sharp drivers. No sweat, done.

Problem, now A TON of reports in Access 2003, SP 3 running under Widows XP, SP3 are erroring out when we try to open them. Some of these reports are mission critical.

The error happens any time a report is opened. "There was a problem retrieving printer information for this object.  The object may have been sent to a printer that is unavailable."

I think that what happened is that some (many) reports had specified "use specific printer" rather than "use default printer." Now that the old printers (Sharps) that had been "specified" are no longer on site and the drivers are no longer installed on end-user desktops, the reports are apparently trying to query the printers when opening the reports. But the printers are no longer there physically or in terms of drivers. Thus the error message.

Bigger problem, this appears to prevent correction of the error since the error pops up whenever you try to run the report, open the report in design view or select the report and go to the file menu to select "page setup" (design view & setup have been suggested by many around the web as a solution). Since we can't open page setup or design view, there seems to be no obvious way fix this error? Anyone have an alternate method, especially of fixing it en masse. Maybe some command line parameter to "set all reports to default printer" (I'm reaching here, I know), so we don't have to go through individually to fix it on a report-by-report basis? That and so we don't have to go through page setup or design view? I mean, it's pretty stupid that the error message precludes opening the windows necessary to fix the error. It's a vicious cycle...

Any help appreciated...

Microsoft 365 and Office | Access | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

Answer accepted by question author

Anonymous
2012-04-06T23:09:43+00:00

Our tech guy has fiddled with the Konica driver's settings slightly to use PS(V) (PostScript 5) rather than PCL for printing. Not sure exactly how that plays into things, but it appears reports are now coming up correctly for the moment...? If not, I'll probably be back. ;)

Was this answer helpful?

0 comments No comments

1 additional answer

Sort by: Most helpful
  1. Anonymous
    2012-04-06T21:36:03+00:00

    Okay, I can give a tiny bit more info. The sharp drivers are still set up on the server, so I've added them back via the network to my own machine. Without setting them as default on my machine, the error persists. If the printer I had set as default before is set as default again, the report comes up. If I subsequently set the default printer on the machine to the new printer, the error pops up again. If I set it back to the old printer the error goes away and I can inspect the page setup, which "claims" to be "default" rather than "specific printer." I noticed, though, that if I set the report to "specify" the new printer then set it to "default" on the Page Setup screen, I think the error goes away on that database file. However, if I open a different database file, the error is right back on the same report. So it seems like the report *is* somehow being associated with a particular printer driver even though it's reporting on the Page Setup window that it set to "default." By clicking "Okay," it seems to set some parameter to ACTUALLY use the "Default" printer and the problem goes away. I may be misreading the situation somehow. It's all very confusing...

    Again, I'd HATE to have to literally to through every single report in the database (it's massive) and individually double-reset the printer to "specify" then unspecify ("default") it... There's got to be a better solution??

    Was this answer helpful?

    0 comments No comments