By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,607 Members | 1,983 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,607 IT Pros & Developers. It's quick & easy.

cannont create SSPI context (SQL connection problem after 30 minutes)

P: n/a
It makes no difference if I'm working with Enterprise Manager, Query
Analyzer, Access, self written app with OleDb or Visual studio 2003
builtin DB manager.

Everything is fine but aufter some time - about 30 minutes I get
message "cannot create SSPI context"

After rebooting my machine I can work for another few minutes.

NB01 is my notebook with Windows XP Pro
SQL01 is another Windows XP Pro machine with SQL Server 2000 desktop
DC01 is the domain controller
all machins within the same domain DOMAIN01
The user is a domain admin and has every right

I'v seen some postings for this problem but not one useful idea how to
As it runs perfectly for some time I don't thint it is a DNS problem or
something like this.
As there is no useful error message it must be some kind of bug.
Has anybody resolved such a problem?

Dec 2 '05 #1
Share this Question
Share on Google+
3 Replies

P: n/a

Razvan Socol wrote:
Hi, equ

Read the following KB articles:


Hi Razvan,

thanks for the links - I'v already read most of thos articles, but
think that they don't solve MY problem. In my case everything is
working for a while after a reboot and then lets say after 30 minutes I
get the mentioned error. If DNS dosn't work correctly between my
machines then why does it work very well for some time?

Same problem occurs when I have everything working (ie after a reboot)
and then put the notebook to hybernate mode. After waking it up again,
the problems start. Probably this is a second issue because I've heared
from many ohter people that hybernation mode makes deep problem with


Dec 5 '05 #3

P: n/a
Hi, Erich

An easy solution may be to use the Named Pipes protocol instead of
TCP/IP: run CLICONFG.EXE and make sure that Named Pipes is at the top
of the enabled protocols list (this is one of the solutions described
in KB 811899).


Dec 5 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.