Intermittent connection dramas: "Cannot open user default database..."

Hi,
I've been experiencing some very strange, intermittent failures connecting
to an MS SQL database... basically at seemingly random times the server
decides that it can't open the requested database (reporting error 4062:
"Cannot open user default database. Using master database instead"). I've
so far been unable to track down any useful background to this error
message; has anyone on this group come across similar problems? Any clues
as to what might be triggering this sort of fault? More specific details
follow:
* In the majority of cases, connection is established correctly (albeit
sometimes a little slowly).
* Connections are being made to the local machine, using straightforward,
static code. The problem isn't something trivial like a mis-typed
database name, incorrect password etc. Re-running the SAME CODE will
eventually succeed.
* The server isn't particularly heavily loaded, and I can perceive no
pattern to the fault (it seems no more prevalent when the
server's busy, nor after any particular events).
* Nothing relevant is documented in the Event Viewer, nor the server logs.
Am I looking in the right place'
* We're running SQL Server 2005 Express Edition, latest service pack...
are there any connection rate limitations on this software? All
documentation I've seen indicates that there are not, but this behaviour
almost suggests that there may be...
* Connecting (from local machine) using php mssql module (latest stable
version).
* Although possibly symptomatic of a DoS, there's no other evidence to
suggest that this is the case (TCP to the service is firewalled).
Would be grateful for any advice on this issue.
Cheers,
Alex.Alex Craven wrote:
> Hi,
> I've been experiencing some very strange, intermittent failures connecting
> to an MS SQL database... basically at seemingly random times the server
> decides that it can't open the requested database (reporting error 4062:
> "Cannot open user default database. Using master database instead"). I've
> so far been unable to track down any useful background to this error
> message; has anyone on this group come across similar problems? Any clues
> as to what might be triggering this sort of fault? More specific details
> follow:
> * In the majority of cases, connection is established correctly (albeit
> sometimes a little slowly).
> * Connections are being made to the local machine, using straightforward,
> static code. The problem isn't something trivial like a mis-typed
> database name, incorrect password etc. Re-running the SAME CODE will
> eventually succeed.
> * The server isn't particularly heavily loaded, and I can perceive no
> pattern to the fault (it seems no more prevalent when the
> server's busy, nor after any particular events).
> * Nothing relevant is documented in the Event Viewer, nor the server logs.
> Am I looking in the right place'
> * We're running SQL Server 2005 Express Edition, latest service pack...
> are there any connection rate limitations on this software? All
> documentation I've seen indicates that there are not, but this behaviour
> almost suggests that there may be...
> * Connecting (from local machine) using php mssql module (latest stable
> version).
> * Although possibly symptomatic of a DoS, there's no other evidence to
> suggest that this is the case (TCP to the service is firewalled).
>
> Would be grateful for any advice on this issue.
> Cheers,
> Alex.
>
>
Make sure the "problem" database isn't configured for auto-close, also
make sure it's not the target for log-shipping, or some other process
that might take it offline to do a restore, etc.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Do you periodically rename, remove, or detach the database?
Do you have any jobs that put the database into single-user mode or
otherwise alter the availability of the database?|||On Fri, 29 Sep 2006 08:14:30 -0500, Tracy McKibben uttered:
[...]
> Make sure the "problem" database isn't configured for auto-close, also
> make sure it's not the target for log-shipping, or some other process
> that might take it offline to do a restore, etc.
Hi Tracy et al,
Thanks for all your advice; so far it looks like the auto-close 'feature'
was most likely the root of my problems (or at least a major factor...);
the system seems to be performing rather more reliably with that disabled.
Cheers,
Alex.|||Alex Craven wrote:
> On Fri, 29 Sep 2006 08:14:30 -0500, Tracy McKibben uttered:
> [...]
>
> Hi Tracy et al,
> Thanks for all your advice; so far it looks like the auto-close 'feature'
> was most likely the root of my problems (or at least a major factor...);
> the system seems to be performing rather more reliably with that disabled.
> Cheers,
> Alex.
>
That auto-close option should NEVER be enabled for a production
database. Another one to watch out for is auto-shrink.
Tracy McKibben
MCDBA
http://www.realsqlguy.com