#50070: Unable to connect to the database <Database Name>

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.

Comments (6)
  1. Anonymous says:

    Chris Gideon has posted a great article with a list of the most common reasons why you’ll see the dreaded…

  2. SamW says:

    We kept seeing this error in a large enterprise deployment and it killed us that we couldn’t figure it out. It would come and go without intervention but often caused alarm. During one intense critsit, we noticed the SQL content databases were struggling to grow (heavily fragmented drive, BIG content DBs, set to grow by 10%). Turned out that this error was surfacing for us every time SQL tried to grow a database so was temporarily unavailable until the action commited successfully. We haven’t seen this documented anywhere else (including MS KB articles) so worth considering if you’re in a similar situation.

  3. bgardner@ifes.org says:

     SamW hit the nail on the head for me. I was getting the 50070 on some content db’s but not on others. After comparing I found that the db’s that were logging the "#50070: Unable to connect to the database " error had auto shrink enabled in the database properties options tab.

    Thanks for clearing this up for me. it’s only been a year!!!

  4. dewing1984@yahoo.com says:


    I recently installed Wss 3.0 and started customization. The next day I came in and when I typed the server name into the address bar I was asked for my authentication details. I thought this was odd as I had installed it to use windows authentication, So i didnt expect to have to do this. I was able to go to the central admin page which all seemed to be working fine. I checked the site collection administrator was set as me "administrator" of the machine. I searched for the database files on my one and only hard drive, C:. Which returned only the config Databases. So what happened to my content databases ? why does central admin work ok and my site collection not ? I am concerned that I will repeat the work and the same thing will happen again. Sorry if i have posted in the wrong place please feel free to redirect me, any thoughts would be most appreciated!!!

Comments are closed.

Skip to main content