Having recently configured fax sending/receiving on both a Windows server (using Windows Fax Services on SBS2003) and a Linux server (using Hylafax on Debian Lenny), I felt compelled to write down a few troubleshooting steps for fixing Caller ID problems. Both of these systems include Caller ID information with received faxes (separate from any TSID), but often this information is missing and it is difficult to determine why. Make sure that each of the following items are satisfied:

• Does the phone line to which the fax is connected have Caller ID service from the phone company? (easy to test using a Caller ID-capable phone)
• Does the modem support Caller ID? (check the specs, or skip to the next step)
• Is Caller ID enabled in the modem? Is it being received? To test this, use the following steps:
  1. Stop the fax service
  2. Connect to the modem using Hyper Terminal, telnet, or cu
  3. Query the status of Caller ID on the modem using AT#CID? (or a different modem-specific command). If the modem reports 0 (disabled), enable it with AT#CID=1 and add this to the modem initialization string so it will be enabled after reboot/reconnect.
  4. While still connected to the modem, make a call to the phone line and watch for Caller ID information to be printed. If no Caller ID information is printed, continue troubleshooting the modem/phone until the information is printed.
  5. Disconnect from the modem when finished and restart the fax service

Once the items above are satisfied, the Caller ID information should be gathered by the fax service and included with received faxes. If not, check that the initialization commands include enabling Caller ID, if it is disabled by default (try restarting the fax service, then step 3 from above. If the Caller ID is disabled, something in the fax service is disabling it - or not enabling it). Otherwise, something else is broken and you should add a comment below on how to fix it.

I recently encountered the following error in Microsoft Access 2000:

Apparently this is a catch-all error for any condition where the database engine (or presumably one thread of the engine) is busy completing a task and something else (such as a VBA macro) attempts to perform a function which requires the engine to perform some task. It is horribly difficult to track down, due to the lack of internal debugging interfaces in Access, but check for macros which may be updating visual elements in a form and getting into a loop (for example, OnCurrent actions cascading in a loop or likewise). In my particular case, the error was only triggered when a filter was applied in a form which contained a subform with a field whose default value depended on a field in the parent form. Once I removed the default value from the field in the subform, the error disappeared. (Note also that this only occurred in Access 2000, not Access 2003)

Good luck in tracking down the source of this error if you encounter it.

In the office we are using an HP OfficeJet 6310 All-In-One (donated by a friend, thanks mate!). I recently encountered a problem while attempting to scan from the device using the provided HP software bundle. The (very uninformative) error message that I received after pressing the Scan Document button was:

The communication problem is often solved by reinstalling the drivers (simply remove the printer from Printers and Faxes and click "Add Device" from the installation CD - no need to reinstall the included software) or by correcting common network misconfigurations (wrong IP, disconnected network cable, etc.). Steps for basic troubleshooting are discussed on HP's Website for USB and Network connections.

If/When the basic troubleshooting procedures don't solve the problem, there is a very involved solution for correcting the driver network connection settings posted by Ken Leon on the HP Forums (along with other useful suggestions/diagnostics in that thread).

However, in one (increasingly common) case, it may be possible to avoid the need to reconfigure the internals of the scanner drivers. If your ISP participates in DNS Hijacking, it may be prudent to rule this out as a cause of the error. It appears that the scan drivers attempt to address the device based on its hostname rather than its IP address (regardless of configuration) and when it resolves the address of the device, the DNS request gets hijacked and the scan drivers attempt to connect to the ISP server instead of the device. To diagnose this, simply disconnect the network from the Internet (and restart the router and computer after disconnecting to clear their DNS cache) and see if the error still appears. If it does, then this is not the problem, if it does not, you have found the problem. To remedy the problem, add an entry to the hosts file which associates the hostname of the device (both the name displayed in its web configuration as the hostname and its MAC address prepended with "HP" as this is often used by the drivers).