May 2, 2008 at 5:50 am
We have an application for a client that is working fine on two workstations in an office, but on the other two receive this error message. From what I've found, the [DBNMPNTW] indicates it is attempting to connect with Named Piped. We've changed the SQL Server configuration to only accept TCP/IP. We've also made sure that Named Pipes were disabled in the Client Protocol. Every time we open from these workstations though, they still insist trying to open with Named Pipes.
Is there anything I can do to either troubleshoot the problem with the named pipes or force the workstations to use TCP/IP past what I've already done? We've tried specifying the network library DBMSSOCN in the application. We've also installed Management Studio on a workstation and it connects fine under default settings.
I'd greatly appreciate suggestions on what to try with this.
May 2, 2008 at 6:19 am
did you specify the ip address of the server in the connection string of the application? This might be silly but worth asking.....;)
Chandrachurh Ghosh
DBA – MS SQL Server
Ericsson India Global Services Limited
Quality is not an act, it is a habit.
May 2, 2008 at 6:34 am
Thanks for the reply. We have tried using the IP instead of computer name in the Data Source part of the connection string. Is there another area that'd be useful?
I also forgot to mention some useful info in the first post. Both machines are XP Pro, Server is 20003, using Express 2005. We also verified that all machines were using latest MDAC. Server needed this updated and restarted after.
May 2, 2008 at 6:47 am
Can you post the connection string you use?
You can force client to use given protocol in connection string by prefixing server name with tcp: or np:
Piotr
...and your only reply is slàinte mhath
May 2, 2008 at 7:00 am
Provider=SQLOLEDB.1;User ID=User;Password=SomePass;Data Source=ServerName\Instance,6006;Initial Catalog=ourdb;MultipleActiveResultSets=True
Provider=SQLOLEDB.1;User ID=User;Password=SomePass;Data Source=ServerName\Instance,6006;Initial Catalog=ourdb;Network Library=DBMSSOCN;MultipleActiveResultSets=True
We've tried both of these. We've also substituted the server name with IP, and have tried different ports.
When we try the connection string with the network library specified, we get "General network error" instead of the original error message, which I thought indicated something wrong in the connection string, but things look ok to me.
May 5, 2008 at 3:08 pm
To update on the situation here, I was able to get these workstations to connect with TCP/IP. I was being dumb and had it connecting to servername\instance instead of the IP address of the server. This fixed the initial connection, however there is a new problem now.
When the user logs into this connection, Information from any of the queries doesn't seem to return. When I look at the activity monitor in Management Studio it says that the wait is ASYNC_NETWORK_IO. I am lucky to have a tech at the client's that replaced the switch and network cards to make sure it wasn't a hardware issue, but the situation hasn't improved. This is still only a problem with two of the four computers in the office.
May 6, 2008 at 4:13 pm
Sorry for the question, but have you checked that the firewall doesn't stand in the way?
Piotr
...and your only reply is slàinte mhath
May 7, 2008 at 5:52 am
Yep, I have verified that there is no firewall on the server or workstation that would be blocking this.
Yesterday the tech had started putting a new hard drive on one of the workstations and doing a clean install of Windows to see if that would then work correctly with our program. This was last night and I haven't gotten an update yet, but will post when I do.
May 7, 2008 at 10:05 am
It looks like the problem is solved with this. The program works fine on a fresh install of Windows. On the 2nd computer having the issues, the tech tried reinstalling SP2 for XP and our program started working again with that. Thanks for all of the help!
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply