Access Doesn’t Recognize Printer (2003 SP2)

Topic

New Reply

This has come up in some recent and not-so-recent (and others, I’m sure) threads…

Several users on a multi-user database of mine have discovered that when they try to print/preview a report, the action is seemingly ignored. For other users, everything works just fine. Upon further investigation (e.g., the threads above), I have determined that this is due to their default printer designation in Windows (it happens to be a network printer). If I open a blank Access database with this same printer designated as the Windows default printer, I can’t even open up a report in design mode, let alone preview it or print it. Page setup for forms is also ignored.

If I change the default Windows printer to another network printer, everything works fine (both for the blank database and for my application). If I select the problematic printer at print time, the report prints to that printer just fine — it appears that having it as the Windows default printer is what confuses Access. All other Office applications seem to work fine with it as the default printer.

I’ve tried re-installing the printer driver, per the guidance in the threads above (it is a network printer, so I guess I’m just re-establishing the link to the network driver, right?), which doesn’t seem to help any. Do I need to get in touch with our network folks to get them to really reinstall the network driver?

Thanks.

Reply | Quote

Replies

It’s certainly worth a try to have the printer drivers installed anew.

Reply | Quote

Had this occur with one of my users last week. The issue, I am told by our desktop support people, is an Event ID 1202 or 1085 showing up in the application log event viewer. This means that the local security policy database is corrupt. To resolve (1) log into the pc with account and admin rights. Rename the c:windowssecuritydatabasesecedit.sdb to secedit.old; (2) Reboot the pc; (3) go into the event view and confirm the errors have gone away.

This cured the problem with my user; hope it can help others.

Reply | Quote

Hello Bill,

I also had this problem happen to me. I have tried doing what you recommend below but it hasn’t worked for me. Can you confirm what you mean about point (3) what is the event view? How do you look into the application log event viewer to locate the errors?

I look forward to your response.

Regards,

Jocelyn

Reply | Quote

Hello again,

I have since located the Application Log Event Viewer but there are no event IDs for 1202 and 1085. Do you need to change the name for the secedit.old file back to its original name again?

Regards

Jocelyn

Reply | Quote

Hi Jocelyn,

Sorry I haven’t goten back to you sooner, but I was out of the office last week. Regardless, When you rename the secedit.sdb file, reboot the pc and then go into the event viewer, those event IDs will be gone because at reboot time, if the system can’t find the file (secedit.sdb), it will create a new one. Hope this helps.

Reply | Quote

With the help of our network support folks, I removed the old printer driver, reinstalled the network printer (e.g., SERVERPRINTERNAME), but this time called it a “local printer” in the Add Printer Wizard, created a new port, a local port, and named the local port the printer name (SERVERPRINTERNAME), browsed to the printer .INF file (our network folks supplied this, but it’s usually available from the printer vendor, too), specified that the old driver should be replaced, and proceeded through the rest of the usual New Printer routine.

This solved the problem.

I’ll be curious to see if Bill Kessinger’s suggestion regarding deleting the security policy file will also solve this problem (I wonder whether this alternative has any undesirable side effects).

Thanks.

Reply | Quote

Tom: Problem solved with no undesirable side effects with this method.

Reply | Quote