So you’ve got a Microsoft Access database with linked tables to a SQL server that looks something like this.
When opening one of the linked table you get an error that says, “ODBC–connection to ‘DP’ failed”.
When you click OK you get a message that says, “Microsoft Access can’t open the table in Datasheet view”.
Hmm, what up with the ODBC connection called “DP”? What say you Procmon?
Result = NAME NOT FOUND. Oh, the ODBC connection doesn’t exist. Create the ODBC connection & you are good to go.
I admit that you could have also just gone & looked at the ODBC connections in the Control Panel to figure out it doesn’t exist but it was really just an excuse to use Procmon.
A user reported that they had printed some documents but that they were not printing. Looking at the print server I saw that the printer was showing as Offline.
I was able to ping it as well as bring up the web interface. As a test I disabled SNMP checking for the printer’s port by doing the following:
- Right click the printer & select Properties.
- Select the Ports tab.
- Select the printer’s port & click Configure Port.
- Uncheck SNMP Status Enabled.
- Click OK.
The moment I did that the printer went to a Ready status & the documents printed. I have two printer server that both have this printer configured. They were both experiencing the issue so I believe the issue to be with the print servers.
OK, perhaps the SNMP string got changed on the device. I ran an SNMP test (Paessler has a good free one http://www.paessler.com/tools/snmptester) but it check out good using the SNMP string configured on the printer’s port.
So when in doubt use ProcMon. First, I set the printer’s port back to using SNMP checking then fired off ProcMon on the printer server. Within a minute the printer switched from Ready to Offline. I stopped ProcMon & begun the artful task of sifting through the capture. I noticed a section where the print server starting sending SNMP requests to all the printers. I saw a response for all the other printers but none for the one in question. Note below all I saw were UDP Send.
So for some reason the printer is not responding (or not responding timely. I didn’t feel like doing a full on packet capture). So like everything else if it’s not working, reboot. Once the printer came back up it I started another ProcMon capture. This time I saw the SNMP requests & responses (UDP Send & UDP Receive).
Sure I could have just left SNMP unchecked on the printer port but that wouldn’t have really resolved the issue; just masked it. Now if it continues to happen I may have to see if there is a newer firmware for the printer that resolves SNMP issues (or contact HP, ugh), but for now a printer reboot will do the trick. I also got to see a little more under-the-hood thanks to ProcMon.