 |
|
|
|
Next: Log File Recovery.
|
| Author |
Message |
External
Since: Jan 15, 2007
Posts: 80
|
(Msg. 16) Posted: Wed Mar 26, 2008 8:49 am
Post subject: Re: SQL Server 2000 SP4 client connection problem [Login to view extended thread Info.]
Archived from groups: microsoft>public>sqlserver>connect (more info?)
|
|
|
It's difficult to offer more advice since you have checked so much stuff
already, but I don't want to ignore you when you can't connect. I think it's
time to review everything again. Of course I understand if you don't want
to.
Since you will be connecting using TCP I will ignore named pipes.
On the server:
- Is the SQL Server Service started?
- Can you connect to SQL Server locally?
- Does the SQL Server error log say that SQL Server is now listening on TCP
port 1433? If another port number what? The expected entry should read: "SQL
server listening on <IP address>: <port number>."
- Does the Windows firewall have an exception for TCP port 1433? (or
whatever port is being used) (or is the firewall stopped)
- Does the firewall have any other restrictions, like only allowing
connections from certain computers or subnets?
- Is there another firewall?
- Was SQL Server 2005 or SQL Server 2008 ever installed on this computer? If
so you may have a SQL Server Browser issue.
- Are there any interesting errors in the SQL Server error log or the
Windows event log?
On the Client:
- Can the client successfully ping the TCP address of the server?
- Can you connect without resolving the computer name, but just using the IP
address and port in the format: <computer name>,<port number> like
155.155.96.94,1433 ?
- On the client, are there any client aliases that may be redirecting the
connection?
- Is the client connection attempt using the same credentials as the
successful local connection?
- Are you getting any errors except "SQL Server does not exist or access
denied."?
- Are there any interesting errors in the Windows event log?
Sorry, but I'm running out of suggestions about here.
--
Rick Byham (MSFT)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Charles Calvert" <cbciv DeleteThis @yahoo.com> wrote in message
news:lgr7u3tdv78ode00o01ba233hgsequcdpg@4ax.com...
> On Fri, 21 Mar 2008 12:39:38 -0400, Charles Calvert <cbciv DeleteThis @yahoo.com>
> wrote in <9el7u356i0tggnuje1hkkhf7jvrlce8m80 DeleteThis @4ax.com>:
>>
>>I checked in the SQL Server Network Utility and both named pipes and
>>TCP/IP are in the "Enabled protocols" list. TCP/IP's "Default port"
>>property is 1433 and "Hide server" is not checked.
>>
>>I disabled named pipes and restarted the server. Now on ClientA
>>(which was working before), I get the error:
>>
>>Unable to connect to server <ip address>
>>
>>Server: Msg 17, Level 16, State 1
>>[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist
>>or access denied.
>>
>>If I browse for available servers in the "Connect to SQL Server"
>>dialog of Query Analyzer, the server no longer appears.
>
> I uninstalled and reinstalled SQL Server on the server, only enabling
> TCP/IP this time. Since the server runs W2K3, I had to install SP3.
>
> This has gotten me nowhere. I still get the error listed above from
> ClientA, which worked before I disabled named pipes.
> --
> Charles Calvert | Software Design/Development
> Celtic Wolf, Inc. | Project Management
> http://www.celticwolf.com/ | Technical Writing
> (703) 580-0210 | Research |
|
| Back to top |
|
 | |
External
Since: Apr 15, 2005
Posts: 25
|
(Msg. 17) Posted: Fri Mar 28, 2008 9:47 am
Post subject: Re: SQL Server 2000 SP4 client connection problem [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Wed, 26 Mar 2008 08:49:40 -0700, "Rick Byham, \(MSFT\)"
<rickbyh.DeleteThis@REDMOND.CORP.MICROSOFT.COM> wrote in
<2CBB84D5-E5A9-48B4-BE95-C035F4CD729F.DeleteThis@microsoft.com>:
>It's difficult to offer more advice since you have checked so much stuff
>already, but I don't want to ignore you when you can't connect. I think it's
>time to review everything again. Of course I understand if you don't want
>to.
No, I'm happy to do so. Thanks for your help.
I think that the problem is that TCP has never worked, but ClientA was
able to connect through named pipes, while ClientB was not. Both
methods were enabled on the server and all clients, with TCP taking
precedence. As soon as I disabled named pipes, I could no longer
connect from any client. My goal is now to make TCP work, since I
need to have people access it over the VPN without giving them local
accounts on the server (I'm running a workgroup, not a domain).
>Since you will be connecting using TCP I will ignore named pipes.
>On the server:
>- Is the SQL Server Service started?
According to both the Services Manager and the Services MMC panel,
yes.
>- Can you connect to SQL Server locally?
No, now that named pipes have been disabled. I get the same errors
locally that I do on the clients. The error is:
Unable to connect to server SERVERNAME:
Server: Msg 17, Level 16, State 1
[Microsoft][ODBC SQL Server Driver][DNETLIB]SQL Server does not exist
or access denied.
Note that when attempting to connect locally, it says [Shared Memory]
instead of [DNETLIB]. That's interesting, because while the server
log indicates that it is monitoring shared memory, the client network
utility does not have shared memory enabled.
>- Does the SQL Server error log say that SQL Server is now listening on TCP
>port 1433? If another port number what? The expected entry should read: "SQL
>server listening on <IP address>: <port number>."
Yes, though I'd been working with someone from Microsoft and we
switched to dynamic ports as a test and it's now listening on 1043
instead. It lists both the static IP of the server (e.g.
192.168.1.21) and the loop-back address (127.0.0.1).
>- Does the Windows firewall have an exception for TCP port 1433? (or
>whatever port is being used) (or is the firewall stopped)
Windows firewall is disabled. I determined this by looking at the
properties of the network connection, going to the Advanced tab and
clicking on Settings. I got the message:
Windows Firewall cannot run because the Windows Firewall/Internet
Connection Sharing (ICS) service is not running. To use the Windows
Firewall, you must start the Windows Firewall/ICS service. If you
configure exceptions for applications or services that were running
before you started Windows Firewall, you might have to restart your
computer so that these applications and services run properly. Do you
want to start the Windows Firewall/ICS service?
I have always answered "No" to that question, as I am running
ZoneAlarm instead. Note that I disabled ZoneAlarm during my tests,
both on the server and the clients, to make sure that it wasn't
causing the problem.
>- Does the firewall have any other restrictions, like only allowing
>connections from certain computers or subnets?
N/A.
>- Is there another firewall?
Yes, ZoneAlarm, but it is disabled, as I mentioned above. If
necessary, I'll even uninstall it.
>- Was SQL Server 2005 or SQL Server 2008 ever installed on this computer? If
>so you may have a SQL Server Browser issue.
No. I installed the OS (W2K3) and then SQL Server 2000. I've never
upgraded or downgraded.
>- Are there any interesting errors in the SQL Server error log or the
>Windows event log?
No. In fact, there are no log entries since the server finished
starting up.
>
>On the Client:
>- Can the client successfully ping the TCP address of the server?
Yes.
>- Can you connect without resolving the computer name, but just using the IP
>address and port in the format: <computer name>,<port number> like
>155.155.96.94,1433 ?
No, I get the same error.
On a side note, I am also running IIS on the server, and I can connect
to that successfully both locally and from the clients.
>- On the client, are there any client aliases that may be redirecting the
>connection?
No.
>- Is the client connection attempt using the same credentials as the
>successful local connection?
Yes, I had been trying with the sa account to be sure.
>- Are you getting any errors except "SQL Server does not exist or access
>denied."?
No.
>- Are there any interesting errors in the Windows event log?
The only thing I found was from the server and the event ID was 19011,
description "SuperSocket info: (SpnRegister): Error 1355." I have no
idea what this means.
I should also point out that with named pipes disabled, SQL Server
Agent cannot connect to the server either.
If it weren't for the fact that IIS works, I'd suspect some sort of
sockets problem on the server. Since it does work, I don't know. I
think that my next step may be to format the drive and reinstall. It's
a development server, not a production one, so it won't be too big of
a pain.
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research |
|
| Back to top |
|
| |
External
Since: Jan 15, 2007
Posts: 80
|
(Msg. 18) Posted: Fri Mar 28, 2008 9:47 am
Post subject: Re: SQL Server 2000 SP4 client connection problem [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
When you attempted to connect using the IP address, did you attempt to
connect to: 192.168.1.21,1043
(As a side note, the 192.168.0.0 range of addresses is a private address for
Network Address Translation (NAT). You will not be able to connect to that
address through a router. However, since you can connect to the Internet
Server, you must be on the same subnet, so that is probably not causing the
problem.)
(As another aside, port number 1043 is assigned to "BOINC Client Control" by
the Internet Assigned Numbers Authority {see
http://www.iana.org/assignments/port-numbers} so if you have a BOINC client
{whatever that is} that could cause a problem. This is unlikely.)
Let's try to resolve the local TCP connection attempt first, as it should
have fewer components to mess up.
Locally (on the same computer as the SQL Server) try forcing a TCP
connection through the loopback connector (127.0.0.1) which is the TCP
simplest code path by connecting to: TCP:127.0.0.1,1043
If SQL Server is listening on TCP and if 127.0.0.1 is enabled, and if it's
listening on port 1043, then it's hard to see how this could fail.
--
Rick Byham (MSFT)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Charles Calvert" <cbciv.RemoveThis@yahoo.com> wrote in message
news:hbspu3hn2m5dl26qltlldi36ovdt9resl9@4ax.com...
> On Wed, 26 Mar 2008 08:49:40 -0700, "Rick Byham, \(MSFT\)"
> <rickbyh.RemoveThis@REDMOND.CORP.MICROSOFT.COM> wrote in
> <2CBB84D5-E5A9-48B4-BE95-C035F4CD729F.RemoveThis@microsoft.com>:
>
>>It's difficult to offer more advice since you have checked so much stuff
>>already, but I don't want to ignore you when you can't connect. I think
>>it's
>>time to review everything again. Of course I understand if you don't want
>>to.
>
> No, I'm happy to do so. Thanks for your help.
>
> I think that the problem is that TCP has never worked, but ClientA was
> able to connect through named pipes, while ClientB was not. Both
> methods were enabled on the server and all clients, with TCP taking
> precedence. As soon as I disabled named pipes, I could no longer
> connect from any client. My goal is now to make TCP work, since I
> need to have people access it over the VPN without giving them local
> accounts on the server (I'm running a workgroup, not a domain).
>
>>Since you will be connecting using TCP I will ignore named pipes.
>>On the server:
>>- Is the SQL Server Service started?
>
> According to both the Services Manager and the Services MMC panel,
> yes.
>
>>- Can you connect to SQL Server locally?
>
> No, now that named pipes have been disabled. I get the same errors
> locally that I do on the clients. The error is:
>
> Unable to connect to server SERVERNAME:
>
> Server: Msg 17, Level 16, State 1
> [Microsoft][ODBC SQL Server Driver][DNETLIB]SQL Server does not exist
> or access denied.
>
> Note that when attempting to connect locally, it says [Shared Memory]
> instead of [DNETLIB]. That's interesting, because while the server
> log indicates that it is monitoring shared memory, the client network
> utility does not have shared memory enabled.
>
>>- Does the SQL Server error log say that SQL Server is now listening on
>>TCP
>>port 1433? If another port number what? The expected entry should read:
>>"SQL
>>server listening on <IP address>: <port number>."
>
> Yes, though I'd been working with someone from Microsoft and we
> switched to dynamic ports as a test and it's now listening on 1043
> instead. It lists both the static IP of the server (e.g.
> 192.168.1.21) and the loop-back address (127.0.0.1).
>
>>- Does the Windows firewall have an exception for TCP port 1433? (or
>>whatever port is being used) (or is the firewall stopped)
>
> Windows firewall is disabled. I determined this by looking at the
> properties of the network connection, going to the Advanced tab and
> clicking on Settings. I got the message:
>
> Windows Firewall cannot run because the Windows Firewall/Internet
> Connection Sharing (ICS) service is not running. To use the Windows
> Firewall, you must start the Windows Firewall/ICS service. If you
> configure exceptions for applications or services that were running
> before you started Windows Firewall, you might have to restart your
> computer so that these applications and services run properly. Do you
> want to start the Windows Firewall/ICS service?
>
> I have always answered "No" to that question, as I am running
> ZoneAlarm instead. Note that I disabled ZoneAlarm during my tests,
> both on the server and the clients, to make sure that it wasn't
> causing the problem.
>
>>- Does the firewall have any other restrictions, like only allowing
>>connections from certain computers or subnets?
>
> N/A.
>
>>- Is there another firewall?
>
> Yes, ZoneAlarm, but it is disabled, as I mentioned above. If
> necessary, I'll even uninstall it.
>
>>- Was SQL Server 2005 or SQL Server 2008 ever installed on this computer?
>>If
>>so you may have a SQL Server Browser issue.
>
> No. I installed the OS (W2K3) and then SQL Server 2000. I've never
> upgraded or downgraded.
>
>>- Are there any interesting errors in the SQL Server error log or the
>>Windows event log?
>
> No. In fact, there are no log entries since the server finished
> starting up.
>
>>
>>On the Client:
>>- Can the client successfully ping the TCP address of the server?
>
> Yes.
>
>>- Can you connect without resolving the computer name, but just using the
>>IP
>>address and port in the format: <computer name>,<port number> like
>>155.155.96.94,1433 ?
>
> No, I get the same error.
>
> On a side note, I am also running IIS on the server, and I can connect
> to that successfully both locally and from the clients.
>
>>- On the client, are there any client aliases that may be redirecting the
>>connection?
>
> No.
>
>>- Is the client connection attempt using the same credentials as the
>>successful local connection?
>
> Yes, I had been trying with the sa account to be sure.
>
>>- Are you getting any errors except "SQL Server does not exist or access
>>denied."?
>
> No.
>
>>- Are there any interesting errors in the Windows event log?
>
> The only thing I found was from the server and the event ID was 19011,
> description "SuperSocket info: (SpnRegister): Error 1355." I have no
> idea what this means.
>
> I should also point out that with named pipes disabled, SQL Server
> Agent cannot connect to the server either.
>
> If it weren't for the fact that IIS works, I'd suspect some sort of
> sockets problem on the server. Since it does work, I don't know. I
> think that my next step may be to format the drive and reinstall. It's
> a development server, not a production one, so it won't be too big of
> a pain.
> --
> Charles Calvert | Software Design/Development
> Celtic Wolf, Inc. | Project Management
> http://www.celticwolf.com/ | Technical Writing
> (703) 580-0210 | Research >> Stay informed about: SQL Server 2000 SP4 client connection problem |
|
| Back to top |
|
| |
External
Since: Apr 15, 2005
Posts: 25
|
(Msg. 19) Posted: Fri Mar 28, 2008 12:48 pm
Post subject: Re: SQL Server 2000 SP4 client connection problem [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Fri, 28 Mar 2008 08:44:45 -0700, "Rick Byham, \(MSFT\)"
<rickbyh.DeleteThis@REDMOND.CORP.MICROSOFT.COM> wrote in
<4E64E165-0C75-4D06-A290-2DD76B00550B.DeleteThis@microsoft.com>:
Important note: it looks like I have a corrupted installation. When I
execute "SELECT @@VERSION", I get back 8.00.2039, but when I use
PortQryUI
<http://www.microsoft.com/downloads/details.aspx?FamilyID=8355E537-1EA6-4569-AABB-F248F4BD91D0&displaylang=en>,
I get back version 8.00.129. According to the support engineer at MS,
the latter version is SQL Server 2000 with no service packs, while the
former is SP4.
I'm reinstalling right now. Note that I had already reinstalled once.
I have installed SQL Server 2000 Enterprise, then installed SP4. I
did not bother with previous service packs or hotfixes, because the
download details for SP4
<http://www.microsoft.com/downloads/details.aspx?FamilyID=8e2dfc8d-c20e-4446-99a9-b7f0213f8bc5>
indicate that it includes all fixes from previous service packs.
>When you attempted to connect using the IP address, did you attempt to
>connect to: 192.168.1.21,1043
I tried "tcp:192.168.1.21,1043". It worked via OLEDB locally, but not
via ODBC locally. It did not work using either OLEDB or ODBC from the
clients.
>(As a side note, the 192.168.0.0 range of addresses is a private address for
>Network Address Translation (NAT). You will not be able to connect to that
>address through a router. However, since you can connect to the Internet
>Server, you must be on the same subnet, so that is probably not causing the
>problem.)
Yes, all of the systems are on the same subnet behind a router running
NAT. All three (the server and two clients) are using static IP and
have the subnet mask of 255.255.255.0. Note that I also tested from
two machines that use DHCP instead of static and got the same errors.
>(As another aside, port number 1043 is assigned to "BOINC Client Control" by
>the Internet Assigned Numbers Authority {see
>http://www.iana.org/assignments/port-numbers} so if you have a BOINC client
>{whatever that is} that could cause a problem. This is unlikely.)
BOINC is an open source distributed/grid computing platform used by
various projects such as SETI@Home. See <http://boinc.berkeley.edu/>.
I don't have it installed on any of my systems.
>Let's try to resolve the local TCP connection attempt first, as it should
>have fewer components to mess up.
Agreed.
>Locally (on the same computer as the SQL Server) try forcing a TCP
>connection through the loopback connector (127.0.0.1) which is the TCP
>simplest code path by connecting to: TCP:127.0.0.1,1043
>
>If SQL Server is listening on TCP and if 127.0.0.1 is enabled, and if it's
>listening on port 1043, then it's hard to see how this could fail.
I didn't try 127.0.0.1, though I did try 192.168.1.21. I'll give that
a shot if the reinstallation doesn't fix it.
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research >> Stay informed about: SQL Server 2000 SP4 client connection problem |
|
| Back to top |
|
| |
External
Since: Apr 15, 2005
Posts: 25
|
(Msg. 20) Posted: Fri Mar 28, 2008 5:07 pm
Post subject: Re: SQL Server 2000 SP4 client connection problem [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Fri, 28 Mar 2008 12:48:20 -0400, Charles Calvert <cbciv DeleteThis @yahoo.com>
wrote in <8l5qu39sl9c5h6t595ds1nm97joslerbi3 DeleteThis @4ax.com>:
>On Fri, 28 Mar 2008 08:44:45 -0700, "Rick Byham, \(MSFT\)"
><rickbyh DeleteThis @REDMOND.CORP.MICROSOFT.COM> wrote in
><4E64E165-0C75-4D06-A290-2DD76B00550B DeleteThis @microsoft.com>:
>
>Important note: it looks like I have a corrupted installation. When I
>execute "SELECT @@VERSION", I get back 8.00.2039, but when I use
>PortQryUI
><http://www.microsoft.com/downloads/details.aspx?FamilyID=8355E537-1EA6-4569-AABB-F248F4BD91D0&displaylang=en>,
>I get back version 8.00.129. According to the support engineer at MS,
>the latter version is SQL Server 2000 with no service packs, while the
>former is SP4.
>
>I'm reinstalling right now. Note that I had already reinstalled once.
>I have installed SQL Server 2000 Enterprise, then installed SP4. I
>did not bother with previous service packs or hotfixes, because the
>download details for SP4
><http://www.microsoft.com/downloads/details.aspx?FamilyID=8e2dfc8d-c20e-4446-99a9-b7f0213f8bc5>
>indicate that it includes all fixes from previous service packs.
After working with an engineer from the installation support group,
the product is reinstalled, but Port Query still reports the version
as 8.00.129, whereas everything else indicates version 8.00.2039.
[snip]
>>Locally (on the same computer as the SQL Server) try forcing a TCP
>>connection through the loopback connector (127.0.0.1) which is the TCP
>>simplest code path by connecting to: TCP:127.0.0.1,1043
>>
>>If SQL Server is listening on TCP and if 127.0.0.1 is enabled, and if it's
>>listening on port 1043, then it's hard to see how this could fail.
>
>I didn't try 127.0.0.1, though I did try 192.168.1.21. I'll give that
>a shot if the reinstallation doesn't fix it.
Local connections are now working using TCP (named pipes are
disabled), but the clients cannot connect. The firewalls are turned
off.
Note that the connections appear in the log, but QA hangs, making me
think that the problem is in the handshake or authentication.
The best tool would be a version of QA or similar tool that dumps a
log of the sockets session, but I don't know if such a thing exists.
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research >> Stay informed about: SQL Server 2000 SP4 client connection problem |
|
| Back to top |
|
| |
External
Since: Jan 15, 2007
Posts: 80
|
(Msg. 21) Posted: Mon Mar 31, 2008 9:18 am
Post subject: Re: SQL Server 2000 SP4 client connection problem [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
Well, that's some progress.
If you can connect locally using TCP, the SQL Server must be listening on
TCP properly.
And if you see the connection attempts in the log, then TCP/IP must be
passing something to SQL Server.
So your comment about the handshake or authentication being the problem
makes sense to me too.
Is SQL Server in mixed mode authentication and are you still trying to
connect using sa?
If you are using integrated authentication, there are some possible issues
though they should leave errors in the Windows event log. I'm thinking of
http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=SQ...0Server
though that's pretty obscure.
--
Rick Byham (MSFT)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Charles Calvert" <cbciv DeleteThis @yahoo.com> wrote in message
news:m8nqu3lnaqert0i6bhm4k2h9amolcrcoeu@4ax.com...
> On Fri, 28 Mar 2008 12:48:20 -0400, Charles Calvert <cbciv DeleteThis @yahoo.com>
> wrote in <8l5qu39sl9c5h6t595ds1nm97joslerbi3 DeleteThis @4ax.com>:
>
>>On Fri, 28 Mar 2008 08:44:45 -0700, "Rick Byham, \(MSFT\)"
>><rickbyh DeleteThis @REDMOND.CORP.MICROSOFT.COM> wrote in
>><4E64E165-0C75-4D06-A290-2DD76B00550B DeleteThis @microsoft.com>:
>>
>>Important note: it looks like I have a corrupted installation. When I
>>execute "SELECT @@VERSION", I get back 8.00.2039, but when I use
>>PortQryUI
>><http://www.microsoft.com/downloads/details.aspx?FamilyID=8355E537-1EA6-4569-AABB-F248F4BD91D0&displaylang=en>,
>>I get back version 8.00.129. According to the support engineer at MS,
>>the latter version is SQL Server 2000 with no service packs, while the
>>former is SP4.
>>
>>I'm reinstalling right now. Note that I had already reinstalled once.
>>I have installed SQL Server 2000 Enterprise, then installed SP4. I
>>did not bother with previous service packs or hotfixes, because the
>>download details for SP4
>><http://www.microsoft.com/downloads/details.aspx?FamilyID=8e2dfc8d-c20e-4446-99a9-b7f0213f8bc5>
>>indicate that it includes all fixes from previous service packs.
>
> After working with an engineer from the installation support group,
> the product is reinstalled, but Port Query still reports the version
> as 8.00.129, whereas everything else indicates version 8.00.2039.
>
> [snip]
>
>>>Locally (on the same computer as the SQL Server) try forcing a TCP
>>>connection through the loopback connector (127.0.0.1) which is the TCP
>>>simplest code path by connecting to: TCP:127.0.0.1,1043
>>>
>>>If SQL Server is listening on TCP and if 127.0.0.1 is enabled, and if
>>>it's
>>>listening on port 1043, then it's hard to see how this could fail.
>>
>>I didn't try 127.0.0.1, though I did try 192.168.1.21. I'll give that
>>a shot if the reinstallation doesn't fix it.
>
> Local connections are now working using TCP (named pipes are
> disabled), but the clients cannot connect. The firewalls are turned
> off.
>
> Note that the connections appear in the log, but QA hangs, making me
> think that the problem is in the handshake or authentication.
>
> The best tool would be a version of QA or similar tool that dumps a
> log of the sockets session, but I don't know if such a thing exists.
> --
> Charles Calvert | Software Design/Development
> Celtic Wolf, Inc. | Project Management
> http://www.celticwolf.com/ | Technical Writing
> (703) 580-0210 | Research >> Stay informed about: SQL Server 2000 SP4 client connection problem |
|
| Back to top |
|
| |
External
Since: Apr 15, 2005
Posts: 25
|
(Msg. 22) Posted: Thu Apr 03, 2008 4:10 pm
Post subject: Re: SQL Server 2000 SP4 client connection problem [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)
|
|
|
On Mon, 31 Mar 2008 09:18:13 -0700, "Rick Byham, \(MSFT\)"
<rickbyh RemoveThis @REDMOND.CORP.MICROSOFT.COM> wrote in
<80747295-2AFE-4AFE-B83D-2627147772FA RemoveThis @microsoft.com>:
>Well, that's some progress.
>If you can connect locally using TCP, the SQL Server must be listening on
>TCP properly.
>And if you see the connection attempts in the log, then TCP/IP must be
>passing something to SQL Server.
>So your comment about the handshake or authentication being the problem
>makes sense to me too.
After more testing with the support engineer, we have determined that
OLEDB connections work over TCP, but ODBC connections fail. According
to him Query Analyzer uses ODBC, so I would surmise that osql does as
well.
I seem to have confirmed this, as ClientB, which cannot connect via
named pipes, connects fine when using an OLEDB connection in Crystal
Reports or a System.Data.SqlClient.SqlConnection object in .NET 1.1
(also OLEDB).
The real question now is why ODBC is failing to connect via TCP. We
ran some tests using the Microsoft Network Monitor and I sent him the
logs to analyze.
>Is SQL Server in mixed mode authentication and are you still trying to
>connect using sa?
Yes.
>If you are using integrated authentication, there are some possible issues
>though they should leave errors in the Windows event log. I'm thinking of
>http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=SQL%20Server&ProdVer=10.0&EvtID=17832&EvtSrc=MSSQLServer&LCID=1033
>though that's pretty obscure.
Integrated authentication fails as well, but I'm not, so far as I
know, using Kerberos. All PCs are on a workgroup and authenticating
as local accounts.
--
Charles Calvert | Software Design/Development
Celtic Wolf, Inc. | Project Management
http://www.celticwolf.com/ | Technical Writing
(703) 580-0210 | Research >> Stay informed about: SQL Server 2000 SP4 client connection problem |
|
| Back to top |
|
| |
|
You can post new topics in this forum
You can reply to topics in this forum
You can edit your posts in this forum
You can delete your posts in this forum
You can vote in polls in this forum
|
|
|
|
|
|
|
FAQ
Profile
Private Messages
Log in
