We have a setup in which our users log into an access database using MS Access 2003 over an RDP connection. The backend database (.mdb) is accessed by our users with their frontend database (.mde) and secured through a security database (*.mdw).

The user's login to their own machines first using a roaming profile. They then click an rdp connection file on the desktop and login to the remote server, via RDP, where they use MS Access as the shell; they don't have any access to any of explorer.exe features such as the start menu.

The database they are logging into is more of an application, and provides functionality for entering data, querying data, and running reports via form based menus. It all worked pretty well until we split the database as it was nearing 2GBs in size.

We moved out the payroll data into a separate partition, a database with the same name in a different folder, both of them on the server. Only two tables were moved into this new database partition, and they were re-linked as external tables in the new partition.

Now while everything appears to be working fine data-wise after the split, there's a new issue when our users login via RDP and attempt to run reports: often the report will not display and instead the user sees an error about the click event of the form. At first I didn't even know it was printer-related, as we didn't really change anything related to the printers as far as I knew.

Confused about the error, I talked to the guy who previously worked here and who was in charge of splitting the database, and he told me to tell the users to set their default printers (on their local machines, not on the server) to the "printer" Microsoft XPS Document Writer which isn't a physical printer at all. This allowed the user's to display their reports, but if they want to print out reports, they are required to go to the File menu and select Print, clicking the print icon on the toolbar takes them to a Save As... dialog as would be expected when using the Microsoft XPS Document Writer as your default printer.

It's easy to tell if the user is having a problem because a quick mouseover of the printer icon will yield a tooltip of (none) when they cannot access their reports, and a tooltip of Microsoft XPS Document Writer when they can view the reports. If the user's printer is set to anything other than Microsoft XPS Document Writer as the default on their local machine, then (none) is always displayed when they rdp to the database. The RDP settings are setup to transfer the local printer to the server.

Telling the users to do this to print has been more of a band-aid on the whole situation until we find a better solution and an explanation as to why splitting a database would prevent users from printing or even viewing access database reports. Which is why I'm here asking this question.

Also of note all the printers on the network now show up on the server so that when the users do click File->Print to print their reports on a physical printer, they have to look through a huge list of printers to find theirs in the dropdown. So the little band-aid fix we have is not ideal. Previously, only the printers on the user's local machine displayed here, and not all the printers on the network.

My co-worker seems to think this has something to do with permissions, I personally think it has to do with roaming profiles, and Group Policies which is what I've been reading up on.

I really don't know how to fix this or how it is related to splitting the database.

  • 1
    USING an Access database usually causes worse issues than printing and reporting problems. Count yourself lucky, and beat the Access "DBA" with the nearest hard, blunt object until he'll convert it to use a real database, like MySQL or MSSQL Server Express. Sep 13, 2012 at 0:41

2 Answers 2


Access requires a default printer before it can open reports (design/print/preview). It sounds like your problem is more printers and server configuration than splitting the database. I have also run into rare cases where particular printer drivers would cause Access reports to fail.

From your description of the problem it sounds like they don't have a default printer selected which is causing the failure.

Do your users print at all? If they do then the drivers are setup on the server and their printer gets mapped so why not let them default their normal printer? Not knowing anything about your setup though that is a blind guess.

  • We've been telling them to set their default printers on their local machines to "Microsoft XPS Writer" and that appears to get rid of the issue; but then the users are forced to search for the printer they normal use when they actually do want to print. In their .rdp file we have them go to "Local Resources->Local Devices and resources->Printers" and check it off, so that it carries the default "Microsoft XPS Writer" printer over to the server when they RDP in.
    – leeand00
    Sep 28, 2012 at 14:51

It sounds much more like someone has also made a change to the TS server's published app settings governing printers.

The only way I can think that splitting the DB would do this would be, if the former MDB had some logic to restrict/set the printers and after the split, you're using a new front-end MDB that doesn't have the same logic. However, from your description, the users are still using the same MDB for their front-end, with only a couple of tables that are now links to a new back-end MDB file.

  • You're right, people do use frontends (.mde) files to access the backend. I have no way of telling what is in the backend (.mdb) as far as code.
    – leeand00
    Sep 12, 2012 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.