We were doing a ton of stuff to a named instance of SQL Server at my office yesterday, our QA SQL server to be exact, which sits on the same hardware as our development server. We didn't really do anything to our development (default) instance, other than reboot both nodes of the cluster about six times. Granted, this is going to cause some issues with connectivity, but as there are only two other developers, we were able to keep busy with other projects during the multiple failovers.
For some crazy reason, after I left last night, one of my developers couldn't connect to SQL Server anymore. I put a screenshot up from an application she's developing that connects Access 2007 to SQL 2005 (don't worry, this is a very small application connecting to a database with a very small user base).
I tried running NET TIME on her machine and on the node of the cluster that had ownership of SQL, but that didn't work. I couldn't imagine that the time was different between two nodes of the same cluster, so I didn't bother running it on the other node.
I tried a tracert to the server name, which went out to the Internet. That was strange but not the issue, I don't think.
I deleted and recreated the alias to the server in Configuration Manager. No luck.
I logged onto her machine as me, and was able to connect. Out of curiosity I checked her default database. When I tried to run SETUSER in that database to impersonate her account, it wouldn't let me, giving me an SSPI context error.
I set her default database to one she had user rights in, and that fixed the problem.
I'm really not sure how this could have happened, but it did. I'm just glad to have fixed it relatively quickly. I know there can be all sorts of causes of the dreaded SSPI error, and I just wanted to share what worked for me.
For some crazy reason, after I left last night, one of my developers couldn't connect to SQL Server anymore. I put a screenshot up from an application she's developing that connects Access 2007 to SQL 2005 (don't worry, this is a very small application connecting to a database with a very small user base).
I tried running NET TIME on her machine and on the node of the cluster that had ownership of SQL, but that didn't work. I couldn't imagine that the time was different between two nodes of the same cluster, so I didn't bother running it on the other node.
I tried a tracert to the server name, which went out to the Internet. That was strange but not the issue, I don't think.
I deleted and recreated the alias to the server in Configuration Manager. No luck.
I logged onto her machine as me, and was able to connect. Out of curiosity I checked her default database. When I tried to run SETUSER in that database to impersonate her account, it wouldn't let me, giving me an SSPI context error.
I set her default database to one she had user rights in, and that fixed the problem.
I'm really not sure how this could have happened, but it did. I'm just glad to have fixed it relatively quickly. I know there can be all sorts of causes of the dreaded SSPI error, and I just wanted to share what worked for me.
Comments