I have a user who has this problem: when he prints a report in my program to a certain printer (local), he gets a printer error, then the report won't print out until he reboots his computer (no error within the program itself). This is what I know so far:
He can print the report to any other printer without any problems
No other users have reported problems printing
He has the most recent driver for the printer
He has current windows updates
He has enough RAM
The printer with the problem is a brother printer, and it is a multifunction printer/fax machine.

I am at a loss here - I called the printer company and they say there is no known issue with the driver. I can't have him open access and print a dummy report (to see if the problem is with access) because he is using my program in the runtime version.

Have any of you run into a similar problem before?
:confused:

Can he print from other applications or is it just Access that bugs out?

I have a user who has this problem: when he prints a report in my program to a certain printer (local), he gets a printer error, then the report won't print out until he reboots his computer (no error within the program itself). This is what I know so far:
He can print the report to any other printer without any problems
No other users have reported problems printing
He has the most recent driver for the printer
He has current windows updates
He has enough RAM
The printer with the problem is a brother printer, and it is a multifunction printer/fax machine.

I am at a loss here - I called the printer company and they say there is no known issue with the driver. I can't have him open access and print a dummy report (to see if the problem is with access) because he is using my program in the runtime version.

Have any of you run into a similar problem before?
:confused:
Have you tried to use this printer with other Office applications such as MS Word or Excel? If other MS Office applications work, then the issue must be Access. If they do not, then it is likely the way that the printer is installed on the user's workstation.

Can he print from other applications or is it just Access that bugs out?

Yes, he can print from Word, excel, etc. without any problems.

If other MS Office applications work, then the issue must be Access.

This appears to be the case, but since he can print to other printers from access, I am at a loss for how to fix this.

Is the report being kicked out in .pdf (Access '07)? I had some problems even in Word and IE with the Adobe side of life until I downloaded the latest patch.

-dK

This appears to be the case, but since he can print to other printers from access, I am at a loss for how to fix this.

I am not aware of any issues. Hopefully someone else has encountered this before.

Is the report being kicked out in .pdf (Access '07)? I had some problems even in Word and IE with the Adobe side of life until I downloaded the latest patch.

-dK

Nope - I am in 2003, using docmd.print on a command button.

I am not aware of any issues. Hopefully someone else has esncountered this before.

Here's hoping . . . If I have to get on the phone with brother again I may shoot myself.

My guess is that something is screwy with the references.

My guess is that something is screwy with the references.

I don't know . . . I changed everything over to late binding so the program only has references to the Access object library, DAO, and VBA . . . I thought those were the harmless ones?

I would examine the creation dates etc of the ref'd files in a working verision and see how they compare to the ones where it doen't work - ?

I would examine the creation dates etc of the ref'd files in a working verision and see how they compare to the ones where it doen't work - ?

Do you mean the dates of the dlls that are referenced? I know they are all identical because the installation package includes them and registers them.

Oh... Hum.

I would build an entirely new .mdb with real simple report to print and deploy it and see if it works. It may just be something in the original file you deployed. Just a stab in the dark but it should eliminate a range of potential issues...

Found this ... althought it's for a slightly different problem. Perhaps access is overloading the printer buffer causing the need to reboot ...

Increase the time-out setting for a printer driver

Increasing the time-out setting for a printer driver to 90 may resolve this error message. On the Details tab of the Printer Properties dialog box, extend the two time-out values to 90. They default to 15.

-dK

Both good suggestions - I will try them and report back. Thanks guys!

Is it possible that your form is too large for the print area of the printer?

Is it possible that your form is too large for the print area of the printer?

Anything is possible :)
But I don't think that is it because after he reboots, the report does print out just fine (it is a standard report size that prints on standard 8.5 by 11 paper).

Last ... is the report based on a pivot table? This seems to be a known issue that it takes earlier versions of Access awhile to print these types.

I guess I am asking is it happening with all reports or a specific one?

-dK

Last ... is the report based on a pivot table? This seems to be a known issue that it takes earlier versions of Access awhile to print these types.

I guess I am asking is it happening with all reports or a specific one?

-dK

Not exactly. It is a main report with two subreports, one of which has it's own subreport. One of the subreports is based on a crosstab, but I was having issues with that so now it writes the results of the crosstab to a temp table, and the report is generated off of that. The report does take awhile to generate, but I think that is mostly due to the code in the on format and on print events that counts up various things.

There is only one report in this program, so I think the idea of doing a dummy program with a simpler report is probably a good one.

In the for what it's worth category I have something similarily weird. I am using Access 2003.

I try to print a specific report to a network printer. But it won't print in colour! All other reports are fine. If I print to a pdf file first I can then print in colour. This only happens with one particular report printing to a network printer. It doesn't happen when I use a local printer. Or with any other reports in the same database. I am the only user. I have given up trying to figure out what is going on.

Once I open the database there are no initial problems. Troubles start to occur if I switch the windows focus from the database to another program - say Word or Excel - then back to the database. After that point - no colour for that report when printing to the network printer. As I said it doesn't affect any other report.

Weird. I am not looking for a solution to this, but it is nice to know I am not the only one experiencing this.

I hear you - if I can't solve this problem for my user, I am going to chalk it up to the will of the Access printing gods, whom I have apparently angered somehow.

OK, let's do a process of elimination.

1. He can print to other printers. This rules out the entire body of Access.

2. The problem only applies to one specific printer, which is like other printers you have in your general area. This doesn't exhonerate the printer driver 100% but it does tend to point elsewhere. It has been a while since I tried this, but there are rules about how tightly Access binds to its printer. So...

a. Is the printer this person's deault printer. If not, make it so.

b. Can your user define a default printer to send the report to a file followed by separate output of the now-formatted file to the printer?

3. Nobody else has this problem even with the problematic printer. This means the printer is probably good, too.

4. That leaves the network between computer and printer. I would ask my network guys to check for possible firewall rules between that one user and the printer in question. You are looking for something that would affect one of the lesser TCP/IP sub-protocols. Not LDAP but perhaps SMB or MS Sharing protocols. If this user is in the same network segment as others who CAN use the same printer, then it can only be an Access Control Entry that somehow affects that one user.

I had something similar a while ago but in excel. It turns out vba looks at printers differently and assigns it to a variable type item. I will post an example when my child has gone to bed...

Nigel

In the mean time, try a simple macro record in excel using a print scenario and then check the coding.

Thanks for replying doc man!

OK, let's do a process of elimination.

1. He can print to other printers. This rules out the entire body of Access.
Yep

2. The problem only applies to one specific printer, which is like other printers you have in your general area. This doesn't exhonerate the printer driver 100% but it does tend to point elsewhere. It has been a while since I tried this, but there are rules about how tightly Access binds to its printer. So...

a. Is the printer this person's deault printer. If not, make it so.

Yes, it is his default printer.

b. Can your user define a default printer to send the report to a file followed by separate output of the now-formatted file to the printer?

I don't think I quite understand this point?

3. Nobody else has this problem even with the problematic printer. This means the printer is probably good, too.

Well it is a local printer, so he is the only one that can use it, but you bring up a good point. One way to completely rule out the printer driver as the source of the problem would be to install that same printer on another computer, and see if the same issue occurs.

I had something similar a while ago but in excel. It turns out vba looks at printers differently and assigns it to a variable type item. I will post an example when my child has gone to bed...

Nigel

In the mean time, try a simple macro record in excel using a print scenario and then check the coding.


I'm not sure what you mean about vba and printing . . . my code just does docmd.print to open the standard print dialog.

Thanks everyone who helped - finally got this one solved. It turned out that the user did NOT have all his updates - he assured me that he did, but when I made him to go to microsoft updates and do a custom scan, it turned out that there were additional updates he did not have that fixed the problem. Lesson learned: never trust a user that says he has all his updates!

In regards to the title of your thread? My experience has been that about 90% of the time I find that it is the user who is crazy, but I never say this aloud because of the 10% of the time where it is not.:p :rolleyes:

Wow, 10%, you must have really good users. I would have said 5% . . . :)

Wow, 10%, you must have really good users. I would have said 5% . . . :)

Actully, it is I who tends to go crazy after working several 60+ hour weeks in a row.:D

Whenever I start to work too much overtime, I just remind myself that I every overtime hour I work is an hour I just gave my boss for free. That usually snaps me out of it pretty quickly.

I have been paid by the hour up to 60 hours/week if I wanted/needed to. I try to keep it between 40-50.

Just a thought, if the computer is on a network, can you sign on his computer and print?