I moved to a new Windows 7 PC and now I need to specify "Network Library=DBMSSOCN" in my connection string. On my old Windows 7 PC, my connection string is
Provider=SQLOLEDB.1;Persist Security Info=False;Initial Catalog=;Data Source=;User ID=;Password=" and that works just fine. However, on my new computer if I run that connection string I get the error message "[DBNMPNTW]Connection broken." I know this is the DLL for named pipes. For some reason my pc is defaulting to the named pipes dll instead of tcp.
I have a lot of old apps out there and don't want to have to change and recompile everything to work on my pc. How do I change my system to default to tcp? The only differences between the two pcs are:
Old - Windows 7 x86 New - Windows 7 x64
Old - SQL Server 2008R2 New - SQL Server 2012
Try:
Click Start -> Run
Type cliconfg
click OK
Does Named Pipes have a higher priority than TCP/IP?
Alternatively, you could disable named pipes for SQL Server. To do this:
Click Start -> Programs -> Microsoft SQL Server -> Configuration Tools -> SQL Server Configuration Manager
Expand SQL Server Network Configuration
Disable Named Pipes.
Related
I've built an application in vb.net with Visual Studio 2015 which I need to update now. I need to update the Table Adapter through Dataset Designer but when I click Configure on the Query I get the error:
Failed to open a connection to the database
"The client was unable to establish a connection because of an error
during connection initialization process before login.
Possible causes include the following: the client tried to connect to
an unsupported version of SQL Server; the server was too busy to
accept new connections; or there was a resource limitation
(insufficient memory or maximum allowed connections) on the server.
(provider: Named Pipes Provider, error: 0 - No process is on the other
end of the pipe.)"
Check the connection and try again.
Previously this worked just fine. The application still works fine and connects to the MS SQL server using the same connection string. I'm using the .NET Framework Data provider for SQL Server. See images.
Dataset Designer -> Configure / Edit Query
Error message after I click on Configure + Connection String
It's important to note that the application connects using the same Connection String and everything worked fine previously.
SOLVED! Figured out the problem. The "Named Pipes" setting in the SQL configuration was disabled. First I tried to access the server via IP address and succeded. Then I checked under SQL Server Configuration Manager -> SQL Server Network Configuration -> Protocols for -> Named Pipes and it was Disabled. I've set it to Enabled. I have no idea why it switched do Disabled, it was not like this before.
I had built an application to connect to MySQL DB and SyBase - SQL Anywhere DB using VB.NET and appropriate ODBC connections. This was working fine until we had to make this application a service which keeps running in the background irrespective of any users logged in.
I built the application into a service and after installation, the service was able to successfully connect to MySQL DB, but I am getting the following error when connecting to SyBase (please note the connection string is exactly same as used in the application)
ERROR [08001] [Sybase][ODBC Driver][SQL Anywhere]Database server not found
The project installer - service process installer 1 is configured as localsystem.
The creepiest thing here is, mysql connection is successful, when the same application was not a service, connecting to sybase was successful. Once it was made into a service it started failing. I have a Windows 7 64-bit workstation and VS 2010.
I have been trying to do every single thing for the last one week to fix it but nothing seems to be working. Any advice would be highly appreciated.
Looks like you are using a DSN to connect to SQL Anywhere.
First, make sure that you have configured it as a System DSN. Then, verify that you are using a TCP/IP connection protocol (ODBC Admin -> Select System DSN tab -> Select DSN in list -> Click Configure -> Goto Network tab) and NOT Shared Memory.
Using Shared Memory will NOT work from a Win Service that tries to connect to a SQL Anywhere DB Server.
I suspect that is the issue since you are able to connect from a desktop app using the same connection string.
One way to make this work is to start your SQL Anywhere db as a network server (Start -> All Programs -> Sql Anywhere 12 (or 11, depending on your setup) -> SQL Anywhere -> Network Server.
That should run the dbsvr12.exe, which will start listening for connections on a TCP port.
Then, add a Links=tcpip, or a Host=localhost to your Win Service connection string and give that a try!
Take notice that simple win app is running with credentials from logged user, while windows service is running on system account (in your case). You have two options, change connection string to connect with specific user (if you are now using trusted connection) or change windows service logon user to your user.
I have a web server (Coldfusion) and 2 remote networks that have SQL servers. For both remote offices/networks I query for data every 10 minutes. It has been working for some time now. In one of the offices/networks, AT&T dumped our public static IP address. They assigned a new one and I have made the appropriate changes to the firewall. Now I can use the Windows ODBC manager and test the connection from the web server and it passes just fine. But, when I try to verify the Coldfusion data source, it fails, "timed out trying to establish connection".
ColdFusion 9 doesn't use the Windows ODBC drivers; it uses JDBC drivers. Changing the Windows ODBC drivers and testing them will have no affect on your CF sites.
Update your DSNs in ColdFusion Administrator. Remember, you access your CFAdmin via:
http://localhost/CFIDE/Administrator
unless you've specifically changed it during install. Obviously, replace "localhost" with the server's IP or hostname if it is externally hosted.
ADDENDUM
The exception to the above rule is when you are using the ODBC-JDBC Bridge (CF DSN type = "ODBC Socket"), in which case, you need to verify that:
a) The Windows ODBC Driver (System) is set up, tested, and working, and
b) The CF DSN is pointing to the correct Windows ODBC Driver.
If you are using Windows Server 2008 64-bit, then you may be having trouble with your ODBC because you could be looking at the 64-bit connection list, rather than the 32-bit. In this case, you will have to open up c:\windows\syswow64\odbcinst.exe to access the 32-bit ODBC manager (yes, you read that right; the 32-bit version is under a folder named syswow64).
It sounds to me like there is a good chance that the driver settings you need to update are there, instead of those found registered under the 64-bit ODBC manager (which is the default ODBC manager under control panel). You may have actually had duplicate ODBC entries, one under the 64-bit list and one under the 32-bit list, and this could be the source of the confusion - CF could be using the 32-bit version. In any case - this would be a good thing to check.
I have several servers with SQL Server 2008 R2 instances on them, and alias doesn't work on any of them.
Clients connect to these servers using TCP/IP without any problem, telnet works on IP/Port I use for my alias, the firewall exceptions are created, basically everything works fine, except when I create an alias, I can not connect through it to my server using either TCP/IP or named pipes (local or one of other servers).
I've installed latest cumulative updates, which updates native client too (which I think is the source of problem) and I still have the problem. The stranger part is, if I create an alias on a server with sql server 2005 (native client 9), I can connect to my 2008 r2 instances. Any suggestions?
After you are sure, that it's not firewall problem, TCP/IP problem, and you can connect to server regularly without using alias and only have a problem to connect with alias, I have this problem on Vista and Windows 7.
Solution is to set up proper port inside of "SQL Server Network Configuration" inside "SQL Server Configuration Manager".
Here are the steps:
Go to Computer Management -> Service and Application -> SQL Server Configuration Manager -> SQL Server Network Configuration
Notice that you can also open directly SQL Server Configuration Manager (not from Computer management)
Then in SQL Server Network Configuration, if it is not already enabled, enable TCP/IP protocol.
Right click to open properties of TCP/IP protocol
Then on IP Adresses Tab you will have couple of records.
For every one put TCP Port = 1433
If you use x64 operating system, you have two "SQL Server Network Configuration" nodes, one for 32bit and the other for 64bit. Be sure that you have checked those port on both of them.
Good luck
For me it was the sequence of creating the aliases that was important. See this link: W2K8 R2 SQL Alias will not connect
I started by deleting everything, CliConfig aliases and Configuration Manager Native Client config aliases. Then re-create, adding the CLICONFG version first.
run CLICONFG - create your TCP alias (will default to the x64
version if you're on a 64-bit O/S)
From SQL Server Configuration
Manager create the alias under "SQL Native Client 10.0
configuration"
Try to connect using SSMS - it worked for me. If it doesn't you could go on to try the 32-bit set-up. I did this anyway as the application I'm developing which uses the alias is x86.
%SystemRoot%/SysWow64/CliConfg.exe (32-bit version on 64-bit O/S)
"SQL Native Client 10.0 Configuration (32bit)" under the
configuration manager tool.
For me, the answer was to use the 32-bit CLICONFG. Both Management Studio and the application I was trying to install were 32-bit applications on a 64-bit server. Moral of the story is to create both 64-bit and 32-bit aliases.
Are you using named instances? And if so have you checked that the port is statically assigned?
If you are using default instances are you running on a x64 platform? There are aliases for 32bit and 64bit so SSMS on the same box as the database engine would use the alias under the 32 bit section even though the box is 64bit
For me this was caused by me creating the alias on a 64 bit machine but the software running as a 32 bit application.
When in Sql Server Configuration Manager ensure the alias is set under both the following sections:
SQL Native Client {VersionNo} Configuration
SQL Native Client {versionNo} Configuration (32bit)
That way it will be available regardless of processor platform. Of course if you only want the alias available for one platform for some reason, set the appropriate one and not the other.
Try it with the IP address, like 127.0.0.1 instead of your machine name, localhost or .(dot).
In my case it only worked when I placed the port on the connection [server]\[instance],[port]. Example: DBSERVER\OPERATIONS,1433
Also, check that your alias uses listeners that are enabled (is your alias configured to use TCP while your server is only listening via Shared Memory?)
I have a VB6.0 application running at a client's site on Vista SP2. When attempting to connect to a SQL 2005 Express database on a named instance ([edit]running in Mixed Mode - not Windows Authentication Only), on a SBS2008 server, from THREE OF THE FOUR Vista workstations in the office I receive the following errors:
"SQL Server does not exist or access denied"
(Using either the sqloledb provider or SQL-DMO)
Of course, the fourth Vista Workstation connects without a problem.
I've tried;
1) Creating a UDL (data link) file in order to "triple" check my connect strings and even when attempting to connect here (selecting the Microsoft OLE DB Provider) I receive the same error when it attempt to refresh the list of available databases
2) I have checked firewall exceptions on the server and even tried the tests, with the firewall turned off.
3) I have added outbound exceptions for my application to the firewall on the Vista machines.
4) I have installed the SQL2005 Backwards compatibility objects.
5) I have installed SQL Server Management Studio on one of the offending Vista machines and this errors in the same way.
6) I have also simulated the test environment in our offices on virtual machines and of course, no problems...
I guess my question is, how to I find out what is different about the one Vista PC that does connect, as opposed to the three that do not?
(Update) Also:
A Virtual Server has been added to the SBS 2008 Server, running SBS 2003 and all those offending Vista Workstations connect without a hitch??
Can you telnet from the offending workstations to the TCP port that the SQL Server is listening on? (Check the ERRORLOG file to get the dynamic port number.)
Is the SQL Browser service on the server running (required that it is).