MS Access remains not user friendly for printing

November 7, 2012 8:44 AM

I've switched my Access 2010 database from using Switchboard to using a Navigation Form. It's prettier and faster and it makes it impossible to print reports properly.

If I select reportPrintable from my Navigation form, I get to put in my parameter(s). Then I can view it. If I try to print, I print the navigation form around it, too. This happens if I add the print button that Access so kindly provides to the form.

What I have, that sort of works, is a button on the report itself. On Click, I run the macro as follows:

Private Sub Command102_Click()
DoCmd.SelectObject acReport, "reportPrintable", True
DoCmd.RunCommand acCmdPrint
End Sub

This selects the report and prints the current report without the navigation form, but I have to reenter the parameters I used. This isn't reasonable for the long term. There are about a half dozen reports that have to be printed, and each report has either one or two parameters. (Either an ID number, a year, or a year and a month.)

Is there any way to fix this so it works more like the Switchboard used to work, or do I have to go back to it?

posted by jeather to computers & internet (6 answers total)

You can certainly do what you want (Access, for all its faults, can pretty much be bent into doing anything!) but you may have to change your approach.

A report should generally be a separate layout that doesn't have any navigation-type stuff on it (or if it does, it should be minimal stuff, like maybe a "back" or "cancel" button that is set to not print).

It would be kind of difficult to provide code or even pseudocode without seeing your database, but can you just have a form for entering your report criteria with a button that opens a separate report layout?
posted by bcwinters at 9:29 AM on November 7, 2012

I can do whatever I want theoretically. Practically I am pretty much self-taught.

I have a report, based on a query. (Multiple reports, each on a unique query.) The query has one or two parameters -- we might need a receipt for ID number 23, or information on all payments made in one month or one year. So when I open the report, it asks me for this/these parameters, then spits out a nicely formatted report, which usually (but not always) has to be printed.

I don't mind having a form for entering the criteria, but would that solve the subform printing problem? Right now my non-tech-savvy people can use this database, so I don't want to make anything more complex on their end.
posted by jeather at 9:49 AM on November 7, 2012

The benefit of using a form for entering the parameters instead of using the simple [What year?] setup (I'm assuming that's what you're doing, it's a bit hard to tell without more detail) is that you can store the parameters and pass them along to another form (rather than "losing" them upon the the next button-press), so the user won't have to re-enter anything.

If anything this could be *more* user-friendly for the non-tech-savvy because it lets you do lots of neat things like have drop downs with month names already in a list, etc etc.

That tutorial in the first link might look long and kinda complicated, but if you walk your way through it piece by piece I think you'll pick up a lot of good practices that will help you down the road.
posted by bcwinters at 12:27 PM on November 7, 2012

Assuming I do this -- have a form to enter the parameters (yes, the [year] setup is what I have), will I be able to continue to use the reports as they exist right now, just add the [Forms]![form]![parameter] to the query the report is based on instead of [year]?

As importantly, if I do this, will it solve my printing problem from the Navigation Form, so that I can print *without* printing the Navigation header and buttons?
posted by jeather at 1:48 PM on November 7, 2012

will I be able to continue to use the reports as they exist right now, just add the [Forms]![form]![parameter] to the query the report is based on instead of [year]?

Yeah, that's pretty much how it works.

if I do this, will it solve my printing problem from the Navigation Form, so that I can print *without* printing the Navigation header and buttons?

What that lets you do is open a separate layout for your report, one that is totally clean and has no navigation or other user interface stuff on it, rather than embedding the form on a page with a bunch of navigation and other junk that you don't want to print.

Do you have screenshots of your database or anything like that? There could be simpler fixes but trying to fix something like this directly is basically impossible without being in front of your actual file, since Access is so open-ended you have a zillion ways of doing the same thing.
posted by bcwinters at 1:58 PM on November 7, 2012

Sure. But what do you want a screenshot of? I really don't know where to start here. I will look into a parameter query, too. I'm 100% sure I've done things very inefficiently in a lot of ways.
posted by jeather at 5:15 PM on November 7, 2012