Printer problems

[The_Doc_Man]

Last time I saw this, it was that setting up network printers can be done more than one way and not all ways work equally well. It might be a driver issue for which the BEST result would be to remove and relink to the networked printers. I had that problem when we switched from HP network printers to Konica/Minolta network printers.

Unfortunately, I don't recall the exact steps I used other than that I started by doing the "add new printer" routine and giving it an IP address (for the device on our local network). The "Add Printer" wizard did the rest, but it was automated and stuff just kind of flashed by on the screen. I know it DIDN'T work when I tried to add a printer by telling Windows to "discover" a printer on our intranet.

 

[sneuberg]

Hasn't this problem been narrowed down to reports in a specific Access Application?

 

[gemma-the-husky]

As you are specifically naming the printer

(\\Panam-dc1\ricoh mp c4503)

then, I would check that the printer is described in this way on the PC's that fail.
ie - that the case of the printer name matches the above.


(hence the alternative and foolproof suggestion of checking all the installed printers until you find one that matches)

I am not sure if giving the printer the full UNC path makes a difference, but it is worth checking.

 

[Eljefegeneo]

The problem has been narrowed down to reports in a specific Application.
The naming of the printers is OK. I double checked then spelling and capitalization, etc. using the module:

  Dim prn As Printer
     Me![cboInstalledPrinters].RowSourceType = "Value List"
           For Each prn In Application.Printers
              Me![cboInstalledPrinters].AddItem prn.DeviceName
    Next

I set up a special form with a combo box to populate the list with the names of all the printers, then went around to everyone's computer and got all the names, pared it down and have a correct list.
I am beginning to believe that the problem is with the network as has been suggested to me more than once. Today I got a report that a simple query export to Excel would not work (hung up) on one computer and functioned perfectly on another. Could it be that a slow network is causing these problems?

 

[gemma-the-husky]

I think you are getting somewhere. now you have a failure in both access and excel, it points to the problem not being an access one.

I am not expert enough on networks, but I suspect it well be the issue.

 

[Eljefegeneo]

As much as I would like to say that the network is the problem as per my last post, the user who reported the problem did not accurately tell me what happened. At work today and checked it. Seems that some code had been inadvertently deleted and thus no code, no export to Excel.

I have re-checked all the print codes that have been causing problems on certain computer/printer hookups and all the print page setups are the same, all codes are the same, etc. Still doesn't work on certain computers/printers and works on others. That is, some need the manual print button on certain printers, others do not.

Updated the print driver on one computer/printer and the latest driver version is now causing problems on a old DOS application still in use.

I have a few more things to try, like setting the printer each time regardless of the default printer. But am still leaning on the network as the culprit.

 

[The_Doc_Man]

According to that great philosopher of the mid-20th century, Elmer Fudd, the first problem in making hasenpfeffer is catching the rabbit. You have not done so. According to your description, this problem is inconsistent with regard to which machine and which configuration exhibits the behavior. In order to find why something works or doesn't work, you must find the pattern, either of what DOES work or what DOESN'T work. ONE of those two cases will have a pattern to it.

To call it a network issue, you will need the assistance of your IT department. Get the IP addresses or MAC addresses of each machine. Make a table of checkmarks showing each system, each problem, and which system has each problem. Leave space for your network team to note the network segment on which each of the workstations resides. See if the problem is segment-specific - which, if it is, would point to routers or intra-segment ACLs that are blocking specific protocols incorrectly.

The next layer of the problem is to check the network setup of each system, which requires you to have access to the network device drivers so you check the protocols enabled on the interfaces. They had better all be the same. If not, that might cause a problem. You might or might not have seen this, but there is a place in your network setup where you can call up an interface and define what is enabled for it in terms of protocols. If not everyone has the same protocol set, that would lead to issues.

After that, you might need the Office Installation disk (or might not, depending on how it was originally installed) to assure that you have a FULL install of all printer options - because printers have different "languages" and you do best to assure that your balky cases have every possible printer option. I.e if something works for an HPGL printer but fails on a PostScript printer, you've found a discrepancy. Many modern printers will "go both ways" or even multiple ways, but if you find that some printers are forced to run in a "compatibility" mode, that might cause a problem. It is better if your version of Office has the mid-level drivers for EVERY major printer control language so that you DON'T run into forcing a printer into a non-standard mode.

Also, to clarify, did you say that your users can see multiple printers from a single workstation? If so, you need to find one user encountering this problem. Have the user try to select a printout of the balky material to each visible printer to see if it works OK on one printer and fails on another for the same exact user, same exact report, same exact workstation. This finding would tell you that the problem is more likely a bad printer setup rather than a network, Office, or Windows issue.

If you've done these experiments, and have all the data, organize it until you see patterns. If not, try to build the spreadsheets to enter and view these patterns. Until you catch the wabbit you won't be making hasenpfeffer.

 

[Eljefegeneo]

You are absolutely right. Was looking for a simple explanation. Will now have each user go through all the reports and tell me exactly what happened when they tried to print each one.

Thank you.

 

[sneuberg]

Did you every get around to trying to print the relationships report,i.e., an Access generated report?

 

[Eljefegeneo]

Yes, and the relationship report printed ok on every computer. Of course, it open the print dialog and you have to click print, not VBA code. Does this mean anything, that the report prints ok?

 

[sneuberg]

Yes, and the relationship report printed ok on every computer. Of course, it open the print dialog and you have to click print, not VBA code. Does this mean anything, that the report prints ok?

That plus the fact that Word and Excel are mostly working ok would lead me away from the network as the problem.

What happens when you print the offending reports directly, i.e., without any VBA involved?

Do you have this problem with other Access applications? If you don't have any, I suggest making a small test application.

Do the reports that are causing problems print from any computer without problems or are they always a problem?

 

[Eljefegeneo]

Thank you again for responding.

I would have to be at work to check out the printing of a report directly, but I should ask what you mean. Is this open in print preview and then print from the ribbon, or do you mean open in report view with a command button and a macro that says PrintObject, or VBA code that prints the report?

I will try to do several variations and then see what happens.

Excel and Word word fine, but then the print is usually from the quick access toolbar on the click on "File" and then print. We do not use any macros or vba for printing of Word or Excel docs.

The one other Access Db that I have distributed to the office does not have any problems. The data is small and the reports are very simple. It is also a split DB.

On my computer at work, I do not have any problems. I can print everything via almost any code. It varies on other computer/printer combos. Some only have to click the manual button on their printer once to print a series of reports coded via VBA, i.e. the VBA says open a report, print it, close it, open the next one, etc. On another, they have to press the manual button on their printer for each report in the series of reports. On another, the printer says that the user has to select the tray. Single reports seem to print without the manual press, multiple page reports may or may not require the manual press.

Likewise on my computer/printer here at home. No problems.

We have tried to update the printer drivers at work, but one update seemed to have caused problems for printing from an old Dos DB.

All the printers are set to be the default printer for their respective local computer.

The server printer that is used by all can be selected via VBA and printed to it without a problem. Or was doing so last week. I will also re-test this and see what happens.

 

[sneuberg]

I would have to be at work to check out the printing of a report directly, but I should ask what you mean. Is this open in print preview and then print from the ribbon, or do you mean open in report view with a command button and a macro that says PrintObject, or VBA code that prints the report?

I meants ways that didn't involve VBA. If it prints ok in these case then this problem to be narrowed down the the VBA.

What are these buttons that have to be pressed? What's their function? When would be a normal thing to have to press the button? If a printer is put in a state where the button needs to be pressed does this block the printing from other applications like Word?

I guess I wondering if Access or this Access application is somehow communicating a need for something the printer is not it a state to provide. Something the user would have to service and then press the button like a change in paper size or a brogan up along side its printhead.

 

[The_Doc_Man]

I don't know what options you have available, but a test that might make sense is to open a report in print preview mode and go through the page setup steps and go through the dialog associated with the "Print..." option when you right-click on the top of the 1st page of a report. Print whatever you need to print to test this problem.

If that fails your test, open the same reports and export to RTF or PDF format (assuming the latter is available) and try to print them by right-clicking on the exported files in whatever folder they were exported to and click the "Print" option. The difference is that you have bypassed the VBA and Access libraries related to the print options. You are using the Windows print routines directly rather than filtered through VBA/Access. If the behavior is the same, it is still hard to say where your problem lies. But if the behavior is different then this is an Access/VBA problem.

 

[Eljefegeneo]

Thanks. will try that.