>>We are really struggling here with error 1957, "Error accessing printer spooler." This error has occurred with some regularity over the past year or so (which is as far back as I have error log data) but for some reason has spiked this month.
>>
>>The error occurs on the second line of code here:
>>
>>m.cLocalMachineName = UPPER(gaPrinters(i,1))
>>SET PRINTER TO NAME (m.cLocalMachineName)
>>
>>I googled "foxpro set printer to name problems" and got some hits. Some were simple user error, for example not referencing the name as a name expression or macro substitution, but others lead me to question the reliability of the command. There was a discussion on "the other FoxPro forum" in 2009 in which the original poster was convinced there is a bug in VFP. He said the default printer is always used regardless of what SET PRINTER TO NAME sets it to. The suggestion was made to issue SET PRINTER TO DEFAULT first. I tried that and it didn't work. There was also a suggestion, which I will try, of changing the printer via a Windows call instead of doing it from VFP.
>>
>>The users and their managers are going a little batty over this. Any suggestions?
>
>This may be too obvious, but make sure the Print Spooler service is running on the local machine. Check System Event Log(s) on various computer(s) to see if there have been any print-related errors.
>
>If you have an unreliable network (e.g. wireless), and the printer is a network printer, a connection dropout might cause problems like that. Maybe you could compare reliability of a network printer vs. one that is locally attached, or a built-in one like the Microsoft XPS document writer or an installed PDF printer driver etc.
>
>Some modern print devices (AIOs etc.) have complex driver software, sometimes with custom print monitors etc. If something is wrong with the driver software you could see symptoms such as you describe. To test for this, you could temporarily install a simple printer/driver combination (such as HP LaserJet 4), to a local port LPT1: (even if neither the printer nor the port actually exist), and test with that.
Here is an update already. I may have found a solution. We will deploy it to a few users in the morning, then roll it out to everyone if the trial is a success. Will come back to the details of the solution later in this post.
Nothing about networks is too obvious for me. Seriously, you know a thousand times more about them than I do, so I appreciate your input. AFAIK none of the situations you mention apply. No user is completely unable to print; the problem is sporadic. I checked the error log and the problem has occurred for 175 distinct logins. (Every user has two of them, for the dinosaur reason that it allows them to view two screens at once). Everyone is wired, not wireless, at least not in the office.
The solution I tried and which seems to work is something I found on foxite.com. No reason to continue being coy about the site, since it may be of benefit to others. The thread was started by a guy in Canada whose name I didn't recognize. (Here it is:
http://www.foxite.com/archives/printer-redirection-vfp-9-issue-0000219973.htm ).
Srdjan Djordjevic, Brad Schulz, Mike Gagnon, and Bernard Bout were participants in the discussion, which gave me confidence it was to be trusted. Someone suggested changing printers with a Windows API call instead of doing it from FoxPro. I don't know if I should quote foxite directly here but if you poke around the thread you will find a function called SetPrinter.prg. It is extremely straightforward, simply calling SetDefaultPrinter in WINSPOOL.DRV. I did some testing and everything worked flawlessly. Tomorrow we will give it some more volume and see how that goes.
What I don't know is why these errors suddenly spiked in the past month. They were averaging about 26 a week over the previous year. This month there have been over 500. At this point I do not consider it a programmatic issue, other than maybe SET PRINTER TO NAME not being reliable. I'll worry about the why later, if at all. Right now I am focused on stopping the bleeding.
Thanks again for the reply.
