|
|
|
date: Wed, 25 Jun 2008 12:43:32 -0500,
group: microsoft.public.sqlserver.clients
back
Re: SQL Server 2005 connection issues.
What error do you get?
--
Rick Byham (MSFT), SQL Server Books Online
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mike Johnson" wrote in message
news:eEWATDv1IHA.5048@TK2MSFTNGP06.phx.gbl...
>I have a problem that has caused whatever hairs on my head that I had left
> to disappear. I distributed an application in a pilot program to over 100
> users on a corporate network using an OLEDB connection string to connect
> to
> a SQL Server 2005 database. Of the 100 plus installs, 10 were not able to
> connect, even though all the computers involved are imaged the same. All
> the
> computers are IBM and they are either PC's or laptops but the same model
> respectively.
>
> After reading a bunch of KB articles on MSDN, it was decided that I use
> SQL
> Native Client drivers rather then ODBC. In the update process, the setup
> utility installed the SQL Native Client drivers to the PC/laptops that
> could
> not connect using ODBC and after checking for a proper installation of the
> drivers, the application still can't connect. Installing SQL Native Client
> on the machines that can connect and changing the connection string to use
> SQLNCLI as the Provider continues to allow them to connect. I have tested
> the SQL Native Client drivers installation on the machines that can't
> connect by creating a DSN using the Native Client drivers and the test
> connection is successful. Any suggestions or solutions?
>
> Thanks,
> Mike
>
>
>
date: Thu, 26 Jun 2008 09:29:50 -0700
author: Rick Byham, \(MSFT\)
Re: SQL Server 2005 connection issues.
Rick,
Thanks for your response. I am getting error "-2147467259 Named Pipes
Provider: Could not open a connection to SQL Server [1231]." at the time of
connection failure. The provider is SQLNCLI and the connection fails
regardless if I use Driver=(SQL Native Client) as a parameter or not. The
other 90 connections do not have the driver parameter and they are
connecting. Some of the workstations that are not connecting are located in
offices where other workstations are connecting so it doesn't appear to be
the network connection to SQL Server. My other issue is that every PC that
we installed the application on at the location that I am at all connect so
I can't even trouble shoot it.
Thanks for any help you can give me.
Mike
"Rick Byham, (MSFT)" wrote in message
news:7BC019E3-B0BF-432F-A432-AA345EBDE183@microsoft.com...
> What error do you get?
> --
> Rick Byham (MSFT), SQL Server Books Online
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> "Mike Johnson" wrote in message
> news:eEWATDv1IHA.5048@TK2MSFTNGP06.phx.gbl...
> >I have a problem that has caused whatever hairs on my head that I had
left
> > to disappear. I distributed an application in a pilot program to over
100
> > users on a corporate network using an OLEDB connection string to connect
> > to
> > a SQL Server 2005 database. Of the 100 plus installs, 10 were not able
to
> > connect, even though all the computers involved are imaged the same. All
> > the
> > computers are IBM and they are either PC's or laptops but the same model
> > respectively.
> >
> > After reading a bunch of KB articles on MSDN, it was decided that I use
> > SQL
> > Native Client drivers rather then ODBC. In the update process, the setup
> > utility installed the SQL Native Client drivers to the PC/laptops that
> > could
> > not connect using ODBC and after checking for a proper installation of
the
> > drivers, the application still can't connect. Installing SQL Native
Client
> > on the machines that can connect and changing the connection string to
use
> > SQLNCLI as the Provider continues to allow them to connect. I have
tested
> > the SQL Native Client drivers installation on the machines that can't
> > connect by creating a DSN using the Native Client drivers and the test
> > connection is successful. Any suggestions or solutions?
> >
> > Thanks,
> > Mike
> >
> >
> >
>
date: Fri, 27 Jun 2008 14:25:13 -0500
author: Mike Johnson
Re: SQL Server 2005 connection issues.
Just guessing, but I'm surprised you have a Named Pipes error. Can you
connect with TCP\IP?
Perhaps all your other computers connect with TCP\IP and the problem
computers have Named Pipes as the preferred protocol instead of TCP\IP.
To check the client protocols, use SQL Server Configuration Manager on the
client computer, expand SQL Native Client, click Client Protocols, and then
look at the order in the list.
--
Rick Byham (MSFT), SQL Server Books Online
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mike Johnson" wrote in message
news:OR4BPNI2IHA.5560@TK2MSFTNGP02.phx.gbl...
> Rick,
>
> Thanks for your response. I am getting error "-2147467259 Named Pipes
> Provider: Could not open a connection to SQL Server [1231]." at the time
> of
> connection failure. The provider is SQLNCLI and the connection fails
> regardless if I use Driver=(SQL Native Client) as a parameter or not. The
> other 90 connections do not have the driver parameter and they are
> connecting. Some of the workstations that are not connecting are located
> in
> offices where other workstations are connecting so it doesn't appear to be
> the network connection to SQL Server. My other issue is that every PC that
> we installed the application on at the location that I am at all connect
> so
> I can't even trouble shoot it.
>
> Thanks for any help you can give me.
>
> Mike
>
> "Rick Byham, (MSFT)" wrote in message
> news:7BC019E3-B0BF-432F-A432-AA345EBDE183@microsoft.com...
>> What error do you get?
>> --
>> Rick Byham (MSFT), SQL Server Books Online
>> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>>
>> "Mike Johnson" wrote in message
>> news:eEWATDv1IHA.5048@TK2MSFTNGP06.phx.gbl...
>> >I have a problem that has caused whatever hairs on my head that I had
> left
>> > to disappear. I distributed an application in a pilot program to over
> 100
>> > users on a corporate network using an OLEDB connection string to
>> > connect
>> > to
>> > a SQL Server 2005 database. Of the 100 plus installs, 10 were not able
> to
>> > connect, even though all the computers involved are imaged the same.
>> > All
>> > the
>> > computers are IBM and they are either PC's or laptops but the same
>> > model
>> > respectively.
>> >
>> > After reading a bunch of KB articles on MSDN, it was decided that I use
>> > SQL
>> > Native Client drivers rather then ODBC. In the update process, the
>> > setup
>> > utility installed the SQL Native Client drivers to the PC/laptops that
>> > could
>> > not connect using ODBC and after checking for a proper installation of
> the
>> > drivers, the application still can't connect. Installing SQL Native
> Client
>> > on the machines that can connect and changing the connection string to
> use
>> > SQLNCLI as the Provider continues to allow them to connect. I have
> tested
>> > the SQL Native Client drivers installation on the machines that can't
>> > connect by creating a DSN using the Native Client drivers and the test
>> > connection is successful. Any suggestions or solutions?
>> >
>> > Thanks,
>> > Mike
>> >
>> >
>> >
>>
>
>
date: Fri, 27 Jun 2008 14:39:59 -0700
author: Rick Byham, \(MSFT\)
Re: SQL Server 2005 connection issues.
The error message that I posted was written to an error log by the software
when the connection failed. I'm going to have to check with the Corporate IT
guys on that (I'm a contract developer) to see if they know what they have
in the field. From my understanding, the only connection to SQL Server on
the field units are the MDAC ODBC drivers. I'm in Florida and all of the
workstations with the failed connections are not. I guess the IT people will
have to do some traveling.
If you can think of anything else, I would be interested in trying it.
Thanks
Mike
"Rick Byham, (MSFT)" wrote in message
news:08765F46-29CF-4CC9-BC6C-6D94FAFAB324@microsoft.com...
> Just guessing, but I'm surprised you have a Named Pipes error. Can you
> connect with TCP\IP?
> Perhaps all your other computers connect with TCP\IP and the problem
> computers have Named Pipes as the preferred protocol instead of TCP\IP.
> To check the client protocols, use SQL Server Configuration Manager on the
> client computer, expand SQL Native Client, click Client Protocols, and
then
> look at the order in the list.
> --
> Rick Byham (MSFT), SQL Server Books Online
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> "Mike Johnson" wrote in message
> news:OR4BPNI2IHA.5560@TK2MSFTNGP02.phx.gbl...
> > Rick,
> >
> > Thanks for your response. I am getting error "-2147467259 Named Pipes
> > Provider: Could not open a connection to SQL Server [1231]." at the time
> > of
> > connection failure. The provider is SQLNCLI and the connection fails
> > regardless if I use Driver=(SQL Native Client) as a parameter or not.
The
> > other 90 connections do not have the driver parameter and they are
> > connecting. Some of the workstations that are not connecting are located
> > in
> > offices where other workstations are connecting so it doesn't appear to
be
> > the network connection to SQL Server. My other issue is that every PC
that
> > we installed the application on at the location that I am at all connect
> > so
> > I can't even trouble shoot it.
> >
> > Thanks for any help you can give me.
> >
> > Mike
> >
> > "Rick Byham, (MSFT)" wrote in
message
> > news:7BC019E3-B0BF-432F-A432-AA345EBDE183@microsoft.com...
> >> What error do you get?
> >> --
> >> Rick Byham (MSFT), SQL Server Books Online
> >> This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> >>
> >> "Mike Johnson" wrote in message
> >> news:eEWATDv1IHA.5048@TK2MSFTNGP06.phx.gbl...
> >> >I have a problem that has caused whatever hairs on my head that I had
> > left
> >> > to disappear. I distributed an application in a pilot program to over
> > 100
> >> > users on a corporate network using an OLEDB connection string to
> >> > connect
> >> > to
> >> > a SQL Server 2005 database. Of the 100 plus installs, 10 were not
able
> > to
> >> > connect, even though all the computers involved are imaged the same.
> >> > All
> >> > the
> >> > computers are IBM and they are either PC's or laptops but the same
> >> > model
> >> > respectively.
> >> >
> >> > After reading a bunch of KB articles on MSDN, it was decided that I
use
> >> > SQL
> >> > Native Client drivers rather then ODBC. In the update process, the
> >> > setup
> >> > utility installed the SQL Native Client drivers to the PC/laptops
that
> >> > could
> >> > not connect using ODBC and after checking for a proper installation
of
> > the
> >> > drivers, the application still can't connect. Installing SQL Native
> > Client
> >> > on the machines that can connect and changing the connection string
to
> > use
> >> > SQLNCLI as the Provider continues to allow them to connect. I have
> > tested
> >> > the SQL Native Client drivers installation on the machines that can't
> >> > connect by creating a DSN using the Native Client drivers and the
test
> >> > connection is successful. Any suggestions or solutions?
> >> >
> >> > Thanks,
> >> > Mike
> >> >
> >> >
> >> >
> >>
> >
> >
>
date: Fri, 27 Jun 2008 20:45:57 -0500
author: Mike Johnson
|
|
