Connecting to SQL 2005 server on Windows 2003

Hope this is on the correct forum, if not could the admins move please.

Im running Win XP SP2 Pro + All updates, Visual Studio .Net 2005 and SQL 2005. SQL is running on Win 2003 server. When i try to create a connection on the WinXP system using ODBC i get the following error:

Connection Failed:
SQLSTATE: '01000'
SQL Server Error: 233
[Microsoft] [ODBC SQL server driver][DBNETLIB]Connection open (PreLoginHandshake())
Connection failed:
SQLState: '08001'
SQL Server error: 11
[Microsoft] [ODBC SQL server driver][DBNETLIB]General Network error. Chcek your network documentation.

Ive searched about the error but nothing seems to work - can anyone help to resolve please?

Thanks in advance.

1) Are you making remote connection? If you have SQL 2005 installed on your XP client box, can you try Management studio to connect to remote server? what error you see?

2) Did you install SQL Express 2005 and make remote connection?If so, check this blog:

http://blogs.msdn.com/sql_protocols/archive/2006/03/23/558651.aspx

But I do not think this is the case.

3) more GNE error troubleshooting blog:

http://blogs.msdn.com/sql_protocols/archive/2006/04/12/574608.aspx

Might give you some clue.

Summary, to fix your problem, please:

check our anouncement posted by Nan Tu, provided the answer to the questions for troubleshootin connectivity issue.

Thanks!

Ming.

connecting to an SQL2005 Server

Hi

I am trying to upgrade a system from SQL 2000 to SQL2005.

I have installed the Server on a PC with Win XP SP2. Using another PC (also Win XP SP2) on the LAN I need to ODBC to the Server.

The Server is NOT the default instance.

I cannot connect via ODBC from the Client PC. This all worked fine with SQL 2000.

As a test I also tried a fresh install of SQL2005 where it was the default instance, this worked fine.

SO the problem is when you have multiple instances.

What do I have to do to sort it out?

Cheers

Eugene

Hi,

What is a error message !? Untill you provide error message we cannot suggest you answer.

Hemantgiri S. Goswami

|||

The error is

Cannot connect to Fred\Fredsql

SQL server does not allow remote connections etc, SQL error 10060

I have used the Surface Area program and Allow remote connections is ticked

Cheers

Eugene

|||Did you had a look in the surface area for this particular instance ? These settings are configured per instance and therefore if you enabled remote connections for the default instance, it does not mean that it is enabled for the named instance as well.

HTH, jens K. Suessmeyer.

http://www.sqlserver2005.de
|||

There are three things that you need to check for...

1) Insure remote connections is enabled for your database instance via the Surface Area Configuration tool for the named instance you are using. By default, SQL Express and DEV SKU has this disabled. Based on the error message posted, this seems to be the issue.

2) Since you are using a non-default (named) instance, this requires that the SQL Browser service to be configured and running properly.

3) Also on Windows XP SP2, you need to insure the firewall exceptions are set up properly. Here is a link with information on how to do this...

http://support.microsoft.com/default.aspx/kb/841249

Hope this helps,

Tom

This posting is provided AS IS with no warranties, and confers no rights.

Connecting to a Remote SQL Server From VB6

Hello,
I'm trying to connect to an SQL 2K server. The problem is that when using XP
it seems to work fine, but in Win 2k it simply does not work. I get an
Unable to fine host error (GetHostserver error). I'm using a dsn/dao to set
up the connection. I do a direct connection (Don't connect to the remote
server) it works fine on both OS.
This is what my cnn string looks like
gstrODBC.DSN = "DSN_NAME"
gstrODBC.DataSource = "Database=DATABASE" & vbCr & _
"Description=CSMisc" & vbCr &
"Server=SQL_SERVER\SQL_SERVER\" & vbCr &
Network=DBMSSOCN"
gstrODBC.Login = "ODBC;uid=USER_NAME;pwd=PASSWORD"
Thank you!!!!
Alex"Alex" <xoxo@.xoxo1.com> wrote:
> Hello,
> I'm trying to connect to an SQL 2K server. The problem is that when using
XP
> it seems to work fine, but in Win 2k it simply does not work. I get an
> Unable to fine host error (GetHostserver error). I'm using a dsn/dao to
set
> up the connection. I do a direct connection (Don't connect to the remote
> server) it works fine on both OS.
--
Hi Alex,
Some steps to troubleshoot connectivity problems from your Windows 200
client to SQL Server 2000:
1. Ping the SQL Server machine name. Does it work?
2. Do a net view to the SQL Server machine. Does it work?
3. Click the test ODBC connection button from the DSN dialogue. Does it
work?
4. See if you can connect via Query Analyzer.
Hope this helps,
-Eric Cárdenas
SQL Server support

Connecting Enterprise manager to SQL 2000

Hi !
I'm running SQL Server 2000 Dev on Win XP Prof and having problem connecting
via Enterprise manager, getting this error in Event-logg:
17310 :
FRunCM: Process 3084 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.
When connecting via SQL Query Analyser everything works fine.
When connecting my Enterprise manager to other SQL-servers everything works fine also.
I've tried both Named pipes, TCP/IP.
My database is having SP 2 but I'm getting an error in sp3_serv_uni.sql when trying to
install SP3A...
Regards,
Fredrik
Check the network libraries at the following registry location.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\ MSSQLServer\SuperSocketNet
Lib
Verify that the service account starting SQL has correct registry and file
permissions.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Thanks for your answer but the service account has full control...
/Fredrik

Connecting Enterprise manager to SQL 2000

Hi !
I'm running SQL Server 2000 Dev on Win XP Prof and having problem connecting
via Enterprise manager, getting this error in Event-logg:
17310 :
FRunCM: Process 3084 generated fatal exception c0000005 EXCEPTION_ACCESS_VIO
LATION. SQL Server is terminating this process.
When connecting via SQL Query Analyser everything works fine.
When connecting my Enterprise manager to other SQL-servers everything works
fine also.
I've tried both Named pipes, TCP/IP.
My database is having SP 2 but I'm getting an error in sp3_serv_uni.sql when
trying to
install SP3A...
Regards,
FredrikCheck the network libraries at the following registry location.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MS
SQLServer\MSSQLServer\SuperSocketNet
Lib
Verify that the service account starting SQL has correct registry and file
permissions.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Thanks for your answer but the service account has full control...
/Fredrik

Connecting Database Engine (SQl server 2005 file .*mdf) from Win CE 5.0 platform

Is this possible to connect do the Database Engine (on sql server 2005 on XP platorm - file *.mdf (not mobile *.sdf)) from win CE 5.0?

I tried to do this :

ConnectionStringSQLServerCE = "Data Source=WORK_STATION\\SQLEXPRESS;Initial Catalog=dbMachines;Integrated Security=False;Password=Panel;User ID=Panel";

SqlCeConnectionCE = new SqlConnection(ConnectionStringSQLServerCE);

SqlCeConnectionCE.Open();

but I catch error:

catch (PlatformNotSupportedException ex)

?PlatformNotSupportedException”

I noticed that I see server because when I use:

ConnectionStringSQLServerCE = "Data Source=WORK_STATION\\SQLEXPRESS";

zwraca b??d typu

catch (SqlException ex)

“Login failed for user ''. The user is not associated with a trusted SQL Server connection.”

I used

using System.Data.SqlClient;

from Compact Framework 2.0 under Visual Studio 2005 Device Application Windows CE 5.0

can anyone help me?

Yes, it is possible to connect to SQL Server 2000/2005, SQL Express and MSDE from NETCF application using SQL Client.

PlatformNotSupportedException usually happens if particular device does not support locale database it in. For example, if your database uses Polish collation, you'd need device localized in Polish in order to use it. Alternatively you could change database collation to one available on device.

As to connection issue, your server need to be properly configured and you should have functional network connectivity. Please see this for general troubleshooting:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=335660&SiteID=1

Connecting client to SQL Server via Cisco VPN

We are having one client PC running Win XP. SQL Server has been set to
Windows Authentication, TCP/IP 1433, Windows 2003 (!).
Via Cisco VPN we are making a connection. IAS has been configurated, so the
local user profile doesn't matter. The server recognizes the user that is
part of the domain that has been defined at the server. So far so good.
When the user tries to connect via any client software (Enterprise Manager,
Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
osql -l -S <hostname> -E
We have used several providers (dail-in, ADSL etc) and some of them works
fine, some not. You would probably say: use the one that works fine, but this
is not satisfying. Some client users are connected to a local network (no
dail in) and do also have the same problem.
The message we got is:
Login failed user '(null)'. Reason: not associated with trusted SQL Server
connection
I have seen at one of the Microsoft pages that we have to set the local
policies correct at the server where the domain has been defined (in case of
Windows 2003). We have done so. No results.
We first thought that it was a problem at the client, but since we have
proved that the same PC can connect to SQL it seems to be a networking
problem. We have also tried Named Pipes as a protocal but we did not succeed.
Since 50% of our clients are not able to connect (this is a world wide
application) we have serious problems. If anyone has any suggestion please
help us.
Thanks in advance
Jeroen
"Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> We are having one client PC running Win XP. SQL Server has been set to
> Windows Authentication, TCP/IP 1433, Windows 2003 (!).
> Via Cisco VPN we are making a connection. IAS has been configurated, so
the
> local user profile doesn't matter. The server recognizes the user that is
> part of the domain that has been defined at the server. So far so good.
> When the user tries to connect via any client software (Enterprise
Manager,
> Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
> osql -l -S <hostname> -E
> We have used several providers (dail-in, ADSL etc) and some of them works
> fine, some not. You would probably say: use the one that works fine, but
this
> is not satisfying. Some client users are connected to a local network (no
> dail in) and do also have the same problem.
> The message we got is:
> Login failed user '(null)'. Reason: not associated with trusted SQL Server
> connection
> I have seen at one of the Microsoft pages that we have to set the local
> policies correct at the server where the domain has been defined (in case
of
> Windows 2003). We have done so. No results.
> We first thought that it was a problem at the client, but since we have
> proved that the same PC can connect to SQL it seems to be a networking
> problem. We have also tried Named Pipes as a protocal but we did not
succeed.
> Since 50% of our clients are not able to connect (this is a world wide
> application) we have serious problems. If anyone has any suggestion please
> help us.
There are a number of areas that these clients could be failing... name
resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
guide will help:
How to troubleshoot connectivity issues in SQL Server 2000
http://support.microsoft.com/kb/827422
Steve
|||Thanks Steve,
The article helped us to get better focus on the issue. Instead of 50% of
the clients, almost all of them cannot connect when the try to establish a
connection via their local LAN.
We are almost sure that port 1433 is the problem. Since we got 3 dial in
providers 1 of them doesn't work. We have seen that NETSTAT -an shows us that
1433 is the problem. We have asked the provider and they have confirmed that
they give a random range of ports available.
Now the local LAN's... We have asked them to open port 1433 ingoing and
outgoing. But it still doesn't solve our problem. The VPN connection is
established via port 80 and this goes fine from any local LAN.
Windows authentication is chosen for a single point of entry. Some people do
not recommend this, but it is supported by Microsoft...
We are really lost, maybe someone has other ideas, maybe we can trace
somehow what goes wrong.
Regards,
Jeroen
"Steve Thompson" wrote:

> "Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
> news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> the
> Manager,
> this
> of
> succeed.
> There are a number of areas that these clients could be failing... name
> resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
> guide will help:
> How to troubleshoot connectivity issues in SQL Server 2000
> http://support.microsoft.com/kb/827422
> Steve
>
>

Connecting client to SQL Server via Cisco VPN

We are having one client PC running Win XP. SQL Server has been set to
Windows Authentication, TCP/IP 1433, Windows 2003 (!).
Via cisco VPN we are making a connection. IAS has been configurated, so the
local user profile doesn't matter. The server recognizes the user that is
part of the domain that has been defined at the server. So far so good.
When the user tries to connect via any client software (Enterprise Manager,
Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
osql -l -S <hostname> -E
We have used several providers (dail-in, ADSL etc) and some of them works
fine, some not. You would probably say: use the one that works fine, but thi
s
is not satisfying. Some client users are connected to a local network (no
dail in) and do also have the same problem.
The message we got is:
Login failed user '(null)'. Reason: not associated with trusted SQL Server
connection
I have seen at one of the Microsoft pages that we have to set the local
policies correct at the server where the domain has been defined (in case of
Windows 2003). We have done so. No results.
We first thought that it was a problem at the client, but since we have
proved that the same PC can connect to SQL it seems to be a networking
problem. We have also tried Named Pipes as a protocal but we did not succeed
.
Since 50% of our clients are not able to connect (this is a world wide
application) we have serious problems. If anyone has any suggestion please
help us.
Thanks in advance
Jeroen"Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> We are having one client PC running Win XP. SQL Server has been set to
> Windows Authentication, TCP/IP 1433, Windows 2003 (!).
> Via cisco VPN we are making a connection. IAS has been configurated, so
the
> local user profile doesn't matter. The server recognizes the user that is
> part of the domain that has been defined at the server. So far so good.
> When the user tries to connect via any client software (Enterprise
Manager,
> Query Analyzer, Access DAP) it sometimes fails. To do this test we used:
> osql -l -S <hostname> -E
> We have used several providers (dail-in, ADSL etc) and some of them works
> fine, some not. You would probably say: use the one that works fine, but
this
> is not satisfying. Some client users are connected to a local network (no
> dail in) and do also have the same problem.
> The message we got is:
> Login failed user '(null)'. Reason: not associated with trusted SQL Server
> connection
> I have seen at one of the Microsoft pages that we have to set the local
> policies correct at the server where the domain has been defined (in case
of
> Windows 2003). We have done so. No results.
> We first thought that it was a problem at the client, but since we have
> proved that the same PC can connect to SQL it seems to be a networking
> problem. We have also tried Named Pipes as a protocal but we did not
succeed.
> Since 50% of our clients are not able to connect (this is a world wide
> application) we have serious problems. If anyone has any suggestion please
> help us.
There are a number of areas that these clients could be failing... name
resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
guide will help:
How to troubleshoot connectivity issues in SQL Server 2000
http://support.microsoft.com/kb/827422
Steve|||Thanks Steve,
The article helped us to get better focus on the issue. Instead of 50% of
the clients, almost all of them cannot connect when the try to establish a
connection via their local LAN.
We are almost sure that port 1433 is the problem. Since we got 3 dial in
providers 1 of them doesn't work. We have seen that NETSTAT -an shows us tha
t
1433 is the problem. We have asked the provider and they have confirmed that
they give a random range of ports available.
Now the local LAN's... We have asked them to open port 1433 ingoing and
outgoing. But it still doesn't solve our problem. The VPN connection is
established via port 80 and this goes fine from any local LAN.
Windows authentication is chosen for a single point of entry. Some people do
not recommend this, but it is supported by Microsoft...
We are really lost, maybe someone has other ideas, maybe we can trace
somehow what goes wrong.
Regards,
Jeroen
"Steve Thompson" wrote:

> "Jeroen" <Jeroen@.discussions.microsoft.com> wrote in message
> news:A750B079-A4AF-4B44-9A84-2E6A227B4029@.microsoft.com...
> the
> Manager,
> this
> of
> succeed.
> There are a number of areas that these clients could be failing... name
> resolution, TCP ports being blocked, etc.. Perhaps this troubleshooting
> guide will help:
> How to troubleshoot connectivity issues in SQL Server 2000
> http://support.microsoft.com/kb/827422
> Steve
>
>

Connect to SQL 6.5 from Win XP Pro

I need to create a system DSN SQL connection (Data Source) on my machine to
a server that is a domain controller in a different domain in preparation
for a C# program I'm writing. It is running NT 4.0 server with SQL 6.5 SP6.
I have an account on that domain but I can't get authenticated even though I
have administrative privileges and we have a trusted connection between the
two domains. What am I doing wrong?
thanks
chuck
Charles,
Check the SQL 6.5 Servers authentication mode. In 6.5 it can be set to
Standard, Integrated, or Mixed. Authentication using trusted connections
will fail if it's set to Standard.
Jon Jahren
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message
news:HjQkd.7644$L92.1112@.newssvr16.news.prodigy.co m...
> I need to create a system DSN SQL connection (Data Source) on my machine
to
> a server that is a domain controller in a different domain in preparation
> for a C# program I'm writing. It is running NT 4.0 server with SQL 6.5
SP6.
> I have an account on that domain but I can't get authenticated even though
I
> have administrative privileges and we have a trusted connection between
the
> two domains. What am I doing wrong?
> thanks
> chuck
>
|||If by C# program, you mean a managed program using datasets, datareaders and
the like; I doubt that you will be able to do so for SQL Server 6.5; as the
..NET environment doesn't offer support for ODBC or OLEDB drivers version 2.5
and less. (I'm not sure about the exact number version, however SQL 6.5 is
quite probably older than the minimum requirement for an SQL-Server OLEDB
driver.)
However, if you intention is to use ADO and interoperability, then of course
you will have no problem.
S. L.
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message
news:HjQkd.7644$L92.1112@.newssvr16.news.prodigy.co m...
>I need to create a system DSN SQL connection (Data Source) on my machine to
>a server that is a domain controller in a different domain in preparation
>for a C# program I'm writing. It is running NT 4.0 server with SQL 6.5 SP6.
>I have an account on that domain but I can't get authenticated even though
>I have administrative privileges and we have a trusted connection between
>the two domains. What am I doing wrong?
> thanks
> chuck
>
|||Oups!
After verification, I'm wrong. The framework 1.1 now allows connection to
ODBC and SQL-Server 6.5. See:
http://www.able-consulting.com/dotne...anagedProvider
S. L.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ejszvxayEHA.2540@.TK2MSFTNGP09.phx.gbl...
> If by C# program, you mean a managed program using datasets, datareaders
> and the like; I doubt that you will be able to do so for SQL Server 6.5;
> as the .NET environment doesn't offer support for ODBC or OLEDB drivers
> version 2.5 and less. (I'm not sure about the exact number version,
> however SQL 6.5 is quite probably older than the minimum requirement for
> an SQL-Server OLEDB driver.)
> However, if you intention is to use ADO and interoperability, then of
> course you will have no problem.
> S. L.
> "Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message
> news:HjQkd.7644$L92.1112@.newssvr16.news.prodigy.co m...
>

Connect to SQL 6.5 from Win XP Pro

I need to create a system DSN SQL connection (Data Source) on my machine to
a server that is a domain controller in a different domain in preparation
for a C# program I'm writing. It is running NT 4.0 server with SQL 6.5 SP6.
I have an account on that domain but I can't get authenticated even though I
have administrative privileges and we have a trusted connection between the
two domains. What am I doing wrong?
thanks
chuckCharles,
Check the SQL 6.5 Servers authentication mode. In 6.5 it can be set to
Standard, Integrated, or Mixed. Authentication using trusted connections
will fail if it's set to Standard.
Jon Jahren
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message
news:HjQkd.7644$L92.1112@.newssvr16.news.prodigy.com...
> I need to create a system DSN SQL connection (Data Source) on my machine
to
> a server that is a domain controller in a different domain in preparation
> for a C# program I'm writing. It is running NT 4.0 server with SQL 6.5
SP6.
> I have an account on that domain but I can't get authenticated even though
I
> have administrative privileges and we have a trusted connection between
the
> two domains. What am I doing wrong?
> thanks
> chuck
>|||If by C# program, you mean a managed program using datasets, datareaders and
the like; I doubt that you will be able to do so for SQL Server 6.5; as the
.NET environment doesn't offer support for ODBC or OLEDB drivers version 2.
5
and less. (I'm not sure about the exact number version, however SQL 6.5 is
quite probably older than the minimum requirement for an SQL-Server OLEDB
driver.)
However, if you intention is to use ADO and interoperability, then of course
you will have no problem.
S. L.
"Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message
news:HjQkd.7644$L92.1112@.newssvr16.news.prodigy.com...
>I need to create a system DSN SQL connection (Data Source) on my machine to
>a server that is a domain controller in a different domain in preparation
>for a C# program I'm writing. It is running NT 4.0 server with SQL 6.5 SP6.
>I have an account on that domain but I can't get authenticated even though
>I have administrative privileges and we have a trusted connection between
>the two domains. What am I doing wrong?
> thanks
> chuck
>|||Oups!
After verification, I'm wrong. The framework 1.1 now allows connection to
ODBC and SQL-Server 6.5. See:
r" target="_blank">http://www.able-consulting.com/dotn...rovide
r
S. L.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ejszvxayEHA.2540@.TK2MSFTNGP09.phx.gbl...
> If by C# program, you mean a managed program using datasets, datareaders
> and the like; I doubt that you will be able to do so for SQL Server 6.5;
> as the .NET environment doesn't offer support for ODBC or OLEDB drivers
> version 2.5 and less. (I'm not sure about the exact number version,
> however SQL 6.5 is quite probably older than the minimum requirement for
> an SQL-Server OLEDB driver.)
> However, if you intention is to use ADO and interoperability, then of
> course you will have no problem.
> S. L.
> "Charles MacLean" <charlesmaclean@.sbcglobal.net> wrote in message
> news:HjQkd.7644$L92.1112@.newssvr16.news.prodigy.com...
>