May 21, 2002 at 2:48 pm
Hi all,
The clients are not able to connect to SQL server using TCP/IP.They are able to connect using Named Pipes .But we need to have both since users in other domain needs access this server.It use to work fine till recently i changed my password.When the clients try to coneect to this server using TCP/IP they get timeout expired error.
Does any one have any idea what's going on ??
Thanks,
MK
May 21, 2002 at 4:50 pm
Changing passwords shouldnt affect your connectivity. Start with pinging from client to server. If that fails switch to tracert to see where it's failing. Probably worthwhile to consult with your network admin.
Andy
May 21, 2002 at 5:24 pm
Andy is right password should not affect the TCP/IP connection. Have you made any other change recently as well? Maybe you installed a piece of software that is not part of SQL but stepped on the TCP/IP stack. Or did the network guys make a router configuration change near your server that is causing packets to be lost or you need to make a change to your adapter setting on the server. Start with what Andy states and also try the ping from the server to a client with issues if the client can ping the server.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 22, 2002 at 2:00 pm
Thanks for the response.In my error log i could see the following messages.
SuperSocket Info: Bind failed on TCP port 1433.
Ic ould ping this server from the client machines without any problem.
Any thoughts.
Thanks,
MK
May 22, 2002 at 4:38 pm
You'll have to restart the service - and possibly the server, so if you can just reboot. I've seen this happens a couple times, never got to the root of the cause.
Andy
May 23, 2002 at 9:24 am
Thanks guys.I jst disabled the TCP/IP from sever Network utility and then enabled.
It's working for me now.
Thanks,
MK
May 23, 2002 at 4:39 pm
That error cames from the OS and means, 'I can open the 1433 port and listen for client conections'. This could be caused by another service that is alredy using this port as it could be caused by a lack of resources in the OS.
quote:
Thanks for the response.In my error log i could see the following messages.SuperSocket Info: Bind failed on TCP port 1433.
Ic ould ping this server from the client machines without any problem.
Any thoughts.
Thanks,
MK
May 24, 2002 at 4:55 am
Both strike me as strange situations to happen. Whats the chance another app on the same server would try to open 1433? I've seen this happen on my 8 proc, 8g box, doesnt seem like it would be short on resources.
Andy
May 28, 2002 at 10:09 am
Hi There....I faced the same problem as Mkumari too...My clients keep on giving me timeout. But after a few tries, only will I be able to connect to the server. I'm wondering whether does the OS affect the routing ?? or the TCP/IP thingy?
Please enlightent me~ LoL....
May 28, 2002 at 11:22 am
Always diagnose the connectivity first. Ping and tracert are great for a start, but sometimes you'll find that its network congestion, bad router/switch, or any of a few other problems that you'll need someone with network knowledge to help you with.
Andy
May 28, 2002 at 1:37 pm
LoL...now I guess I faced another more MAJOR problem over here..
You see....I have 10 machines running simultaneously to connect to a server that operates my SQL SERVER. To my surprise, some of the machines that run on the SAME EXE file that other PCs run, the program is extremely SLOW and I encounter this only on the eve of my demo of my project. Sigh...I'm really having a major headache here..anyone encounter the same problem before? I will be really really thankful if anyone can help me out over here.. 🙁
May 28, 2002 at 7:10 pm
Not much to go on? Are they all using the same stored procs, running the same query? Might just need to do some index tuning. Is the server overloaded?
Andy
May 28, 2002 at 11:32 pm
hhmmm....Overloaded? I'm using 12 clients to connect to the server. Well I guess SQL Server are able to support that much client if i'm not mistaken...: ) heheheh....
Actually, anyone with any idea what's the basic server specs for this kind of server machine that allow so many client to connect simultaneously...:)
Yep...it's all running on the same stored proc and etc..etc...
everything is the same except for the workstation location! LoL...I'm suspecting it's the network congestion and hardward prob but my client just wouldn't accept that explanation...sigh~
gilabean -> soon to be warded...LoL..
May 29, 2002 at 6:10 am
It's not just connections, it's what those connections are doing. Or if you're using Personal Edition, then connections is even more critical since there is a limit. Or you're trying to run it on 128m of RAM.
If you're convinced it's the client and not you, you'll still have to prove it. I'd recommend that you have them run Perfmon for a couple days, log basic server stats and especially focus on the networking part. In addition, log a couple days worth of Profiler info so that when they say "it was slow about 3pm" you can correlate server/network performance to what was actually running at the time. If you can show the query still returned in .00001 secs, then that should help. I'd also recommend getting their network admin involved, he can check router/switch stats to see if any signs of a problem.
Beyond that, you'll have to give us something to work with.
Andy
May 30, 2002 at 8:19 am
Not that it is necessarily the same situation as we have here, but I've dealt with time-out issues here off and on for some time. We're also a software developer and work with clients that want to point fingers at the program/code, but we've always been able to trace it to a networking problem. My first piece of advice is actually to look at the workstations themselves. I don't seem to have any luck internally even with Windows 98 machines. Something with their connectivity and SQL just doesn't always float. Real sporadic, but it's enough to really get you hot. The 9X machines will connect sometimes without any problems, and then at other times, we have to setup an Alias for the server(s) in the Client Network Utility to make it work. Windows NT, 2000, and XP have never given us these problems. Also, have the network admin check his DNS server. This also caused problems here.
Just for info: we're running SQL 7.0 and SQL 2000 servers, MDAC 2.6, with SQL 2000 connectivity and tools installed on all workstations.
Hope that's of some use to those of you with this problem. I've never been able to find any documentation on the issue with Win9x machines and connectivity, but I know from experience that it's a culprit for time-outs.
Regards,
Patrick Purviance
Associated Systems, Inc.
Wichita, KS
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply