Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

#50070: Unable to connect to the database CONFIGDB on SQLSERVER

  Asked By: Amos    Date: Jan 15    Category: Sharepoint    Views: 2462

We keep getting this error in the Application Event log on our WSS server:

#50070: Unable to connect to the database CONFIGDB on SQLSERVER.
Check the database connection information and make sure that the
database server is running.

We've found tons of the advice online on what to try: set the AppPool,
SPTimer, SQL Server, CentralAdmin users to the same domain account.
Check the OLE DB DLL version, etc. So far, we cannot permanently fix
the problem.

We are using a SQL database on a separate SQL server, and have an AD
domain. We are using WSS 2.0. The server used to have SPS installed,
but that was removed.

Weird thing is, the site USUALLY works. Sometimes even when the above
error is showing up in the App Event log. However, often the site goes
down with the generic "Cannot connect to configuration database" error.

So, it doesn't make sense. The site works, but then doesn't work. To
fix it, resetting the SPTimer and IIS Admin services sometimes works.
The App Event log errors even go away for a while. But then the site
seems to break again on its own, or after we restart the entire server.

Is there anything else on the WSS side of things that we should try?

It could be the connectivity to the SQL Server. However, that's weird
too. Usually we can connect to the config database using the
SharePoint Central Admin, even if the SharePoint site is showing the
"Cannot connect to configuration database" error. That doesn't make
sense...

Any ideas that we might have missed? Could the server be hosed beyond
repair?

Share: 

 

9 Answers Found

 
Answer #1    Answered By: M Juarez     Answered On: Jan 15

I would be tempted to back everything up. Reinstall WSS and reconnect to content DB(s). That should give you a solid configDB.

 
Answer #2    Answered By: Marty Mcdowell     Answered On: Jan 15

check the service account  to see if it is locked out.

 
Answer #3    Answered By: Dakota Shaffer     Answered On: Jan 15

Thanks for the suggestion, but it's definitely not locked out, as the
site works  then doesn't work, and I have never had to unlock the
account. I wish it were that easy! :-)

 
Answer #4    Answered By: Ted Gilmore     Answered On: Jan 15

> I would be tempted to back everything up. Reinstall WSS and
reconnect to content DB(s). That should give you a solid configDB.

That may be the final answer. Do I need to uninstall WSS first before
reinstalling?

 
Answer #5    Answered By: Monte Cooley     Answered On: Jan 15

BTW, the answer seems to be a flaky SQL server  connection. I switched
the authentication from Windows Authentication to SQL Authentication,
and the issues, so far, have disappeared. I also reinstalled WSS and
applied SP2, but that didn't help by itself. It appears that the
authentication was the issue afterall, not SharePoint.

 
Answer #6    Answered By: Guadalupe Bullock     Answered On: Jan 15

Be careful, I understand that there are some SharePoint portal features
that depend on SQL Server being in Windows Authentication mode. Mixed
mode is not supported.

 
Answer #7    Answered By: Nathanial Mcclure     Answered On: Jan 15

not running  ipsec betwen firewalls are you? if so, make sure the connection  can be initiated from either side  of the firewall. we had this happen since our SQL is in a private net to protect 1433. SQL could initiate the ipsec traffic, but not vice-versa.

also make sure you sasps windows account  is a security admin  on the SQL server  as well as DB owner on the SPS/WSS DBs.

This might not be it at all, just what I would check  next if applicable.

 
Answer #8    Answered By: Matt Prince     Answered On: Jan 15

We also faced the same error.atlast after so much troubleshooting we
resolved.

The problem  is with the event  logs, if the Security event log  is full
,we are getting this error.after clearing the logs,error resolved.this
is according to our scenario.i am not sure whether this will be same
cause for your problem.

 
Answer #9    Answered By: Brooks Bond     Answered On: Jan 15

circular logging = good

logging to syslog = better :)

 




Tagged: