#50070: Unable to connect to the database

During my trek through Windows SharePoint Services I frequently hear about this error message. I like to refer to “Unable to connect to the database” as one of the dreaded errors of SharePoint. Why would I do this? Because in the majority of cases this is not a WSS problem. It comes from a variety of environmental factors which are difficult to diagnose and troubleshoot. Rather than get into a philosophical debate on the how or why of WSS error reporting in V2 it’s better to just list the causes that I know about.

  1. The Ad Hoc Query Plan bug. Most easily identified with SpSitemanager, first fixed and explained here.
  2. Speed & Duplex Settings NOT Specified for both the NIC and switch.
  3. NIC Drivers misconfigured or a bad NIC driver (no naming names).
  4. A damaged NIC or very rarely a bad/damaged network cable.
  5. Using one VLAN on the switch and then putting both the Internal NIC and the Public NIC on the same subnet.
  6. Unicast mode for WLBS without following the steps in the whitepaper or article. This results in the switch perceiving WLBS as port flooding.
  7. Multicast mode with WLBS without setting up a static ARP entry in the router/switch.
  8. Setting more than one Default gateway on a multi-homed server when both NIC’s are on the same subnet.
  9. Hardware based Load balancing not configured correctly. For an example on configuring this correctly see this.
  10. SynAttackProtect turned on after installing SP1 for Windows Server 2003. This is explained in the SQL Server 2005 release notes but affects SQL 2000 as well.
  11. Not using Aliases when accessing SQL on a port other than 1433.
  12. The SharePoint application pool account locked out.
  13. SQL Server Paused.
  14. A poorly architected web part behaving badly.
  15. High CPU on SQL from another application sharing the same server.
  16. Blocking on SQL server the result of backup software or another application.
  17. Anti-Virus gone awry. Corrected with SP2 for WSS.
  18. App Pool Recycling under load.
  19. Incorrect permissions in SQL server for the SharePoint App Pool account (Need Security Admin and Database Creators).
  20. NTLM Bottleneck see my previous posts for details.

I am certain there are other possible causes. The point is that many of these items are beyond the control of SharePoint. However, I am very pleased with the work the WSS Dev team has done with Beta 2 of V3. Many of the items listed above are caught and reported. I encourage you to try it for yourself.