I had subscribed for free trial for IBM Cognos. In that I have to connect my SQL server with it. I had tried all alternatives but none is working. According to the error, I had even given access of firewall through my system with port defined, also in sql server configuration manager. But still facing the same error when Testing the connection through ibm cognos.By default, we can only connect through jdbc.
Error
Connection In cognos
SQL Server configuration manager
Port Setting Inbound Firewall
The MSSQL database you are connecting to would not be local to the on demand server, so a host of localhost is likely not correct.
If the MSSQL is not publicly accessible you will need to use a secure gateway connection. https://www.ibm.com/docs/kk/cognos-analytics/11.1.0?topic=demand-secure-gateway-only
Additionally, public or private you will also need to add the following to the JDBC connection URL TrustServerCertificate=true
I just installed SQL Server Express 2012 on my home server. I'm trying to connect to it from Visual Studio 2012 from my desktop PC, and repeatedly getting the well-known error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
What I've done to try to fix this:
Run SQL Server Configuration Manager on the server and enable SQL Server Browser
Add a Windows Firewall exception on the server for TCP, ports 1433 and 1434 on the local subnet.
Verify that I have a login on the SQL Server instance for the user I'm logged in as on the desktop.
Verify that I'm using Windows Authentication on the SQL Server instance.
Repeatedly restart SQL Server and the whole dang server.
Pull all my hair out.
How can I get SQL Server 2012 Express to allow remote connections!?
Well, glad I asked. The solution I finally discovered was here:
How do I configure SQL Server Express to allow remote tcp/ip connections on port 1433?
Run SQL Server Configuration Manager.
Go to SQL Server Network Configuration > Protocols for SQLEXPRESS.
Make sure TCP/IP is enabled.
So far, so good, and entirely expected. But then:
Right-click on TCP/IP and select Properties.
Verify that, under IP2, the IP Address is set to the computer's IP address on the local subnet.
Scroll down to IPAll.
Make sure that TCP Dynamic Ports is blank. (Mine was set to some 5-digit port number.)
Make sure that TCP Port is set to 1433. (Mine was blank.)
(Also, if you follow these steps, it's not necessary to enable SQL Server Browser, and you only need to allow port 1433, not 1434.)
These extra five steps are something I can't remember ever having had to do in a previous version of SQL Server, Express or otherwise. They appear to have been necessary because I'm using a named instance (myservername\SQLEXPRESS) on the server instead of a default instance. See here:
Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)
The correct way to connect to remote SQL Server (without opening UDP port 1434 and enabling SQL Server Browser) is to use ip and port instead of named instance.
Using ip and port instead of named instance is also safer, as it reduces the attack surface area.
Perhaps 2 pictures speak 2000 words...
This method uses the specified port (this is what most people want I believe)..
This method requires opening UDP port 1434 and SQL Server Browser running..
One More Thing...
Kyralessa provides great information but I have one other thing to add where I was stumped even after this article.
Under SQL Server Network Configuration > Protocols for Server > TCP/IP Enabled. Right Click TCP/IP and choose properties. Under the IP Addresses you need to set Enabled to Yes for each connection type that you are using.
You can use this to solve this issue:
Go to START > EXECUTE, and run CLICONFG.EXE.
The Named Pipes protocol will be first in the list.Demote it, and promote TCP/IP.
Test the application thoroughly.
I hope this help.
You can also set
Listen All to NO
in the protocol dialog then in the IP address IP1 (say)
set enabled to Yes,
define yr IP address,
set TCP Dynamic to Blank and
TCP port to 1433 (or whatever)
I had this problem recently. 2015 Aug
Solved by opening SQL Server Configuration Manager
SQL Server Network Configuration -> Protocols for SQLEXPRESS
Properties on TCP/IP -> IP Adresses tab
Everything stays default, only set IPALL: TCP Port to 1433
Can connect to with SQL Server Manager to machine: [hostaddress], 1433
Example:
This article helped me...
How to enable remote connections in SQL Server
Everything in SQL Server was configured, my issue was the firewall was blocking port 1433
On my installation of SQL Server 2012 Developer Edition, installed with default settings, I just had to load the SQL Server Configuration Manager -> SQL Server Network Configuration -> Protocols for MSSQLSERVER and change TCP/IP from Disabled to Enabled.
I had to add a firewall inbound port rule to open UDP port 1434. This is the one Sql Server Browser listens on.
I prefer way of "Rosdi Kasim" as that's doesn't require detail configuration on the IP.
I will definitely forget it again when I try to up another server again.
Keep It Simple Stupid (KISS) by simply enable the Sql Server Browser service, then add the \SQLEXPRESS behind the IP when you connect the server.
Direct using IP without "\SQLEXPRESS" was my point of failure as it doesn't use the default port.
Thanks.
I had to add port via Configuration Manager and add the port number in my sql connection [host]\[db instance name],1433
Note the , (comma) between instancename and port
I had the same issue with SQL Server 2014 locally installed named instance. Connecting using the FQDN\InstanceName would fail, while connecting using only my hostname\InstanceName worked. For example: connecting using mycomputername\sql2014 worked, but using mycomputername.mydomain.org\sql2014 did not. DNS resolved correctly, TCP/IP was enabled within SQL Configuration Manager, Windows Firewall rules added (and then turned the firewall off for testing to ensure it wasn't blocking anything), but none of those fixed the problem.
Finally, I had to start the "SQL Server Browser" service on the SQL Server and that fixed the connectivity issue.
I had never realized that the SQL Server Browser service actually assisted the SQL Server in making connections; I was under the impression that it simply helped populate the dropdowns when you clicked "browse for more" servers to connect to, but it actually helps align client requests with the correct port # to use, if the port # is not explicitly assigned (similar to how website bindings help alleviate the same issue on an IIS web server that hosts multiple websites).
This connect item is what gave me the clue about the SQL Server Browser service: https://connect.microsoft.com/SQLServer/feedback/details/589901/unable-to-connect-on-localhost-using-fqdn-machine-name
when you use wstst05\sqlexpress as a server name, the client code separates the machine name from the instance name and the wstst05 is
compared against the netbios name. I see no problem for them to match
and the connection is considered local. From there, we retrieve the
needed information WITHOUT contacting SQL Browser and connect to the
SQL instance via Shared Memory without any problem.
when you use wstst05.capatest.local\sqlexpress, the client code fails the comparison of the name (wstst05.capatest.local) to the
netbios name (wstst05) and considers the connection "remote". This is
by design and we will definitely consider improving this in the
future. Anyway, due to considering the connection remote and the fact
that it is a named instance, client decides that it needs to use
SQLBrowser for name resolution. It attempts to contact SQL Browser on
wstst05.capatest.local (UDP port 1434) and apparently that part fails.
Hence the error you get.
The reason for the "SQL Server Browser" service from TechNet (emphasis added by me): https://technet.microsoft.com/en-us/library/ms181087(v=sql.120).aspx
From the "Using SQL Server Browser" section:
If the SQL Server Browser service is not running, you are still able
to connect to SQL Server if you provide the correct port number or
named pipe. For instance, you can connect to the default instance of
SQL Server with TCP/IP if it is running on port 1433. However, if
the SQL Server Browser service is not running, the following
connections do not work:
Any component that tries to connect to a named instance without fully specifying all the parameters (such as the TCP/IP port or named
pipe).
Any component that generates or passes server\instance information that could later be used by other components to reconnect.
Connecting to a named instance without providing the port number or pipe.
DAC to a named instance or the default instance if not using TCP/IP port 1433.
The OLAP redirector service.
Enumerating servers in SQL Server Management Studio, Enterprise Manager, or Query Analyzer.
If you are using SQL Server in a client-server scenario (for example,
when your application is accessing SQL Server across a network), if
you stop or disable the SQL Server Browser service, you must assign a
specific port number to each instance and write your client
application code to always use that port number. This approach has the
following problems:
You must update and maintain client application code to ensure it is connecting to the proper port.
The port you choose for each instance may be used by another service or application on the server, causing the instance of SQL
Server to be unavailable.
And more info from the same article from the "How SQL Server Browser Works" section:
Because only one instance of SQL Server can use a port or pipe,
different port numbers and pipe names are assigned for named
instances, including SQL Server Express. By default, when
enabled, both named instances and SQL Server Express are configured to
use dynamic ports, that is, an available port is assigned when SQL
Server starts. If you want, a specific port can be assigned to an
instance of SQL Server. When connecting, clients can specify a
specific port; but if the port is dynamically assigned, the port
number can change anytime SQL Server is restarted, so the correct port
number is unknown to the client. ... When SQL Server clients request
SQL Server resources, the client network library sends a UDP message
to the server using port 1434. SQL Server Browser responds with the
TCP/IP port or named pipe of the requested instance. The network
library on the client application then completes the connection by
sending a request to the server using the port or named pipe of the
desired instance
I had a different problem from what all of the answers so far mentioned!
I should start off by saying that I had it in Visual Studio, and not SQL Server Express but the solution should be exactly the same.
Well, god, it's actually really simple and maybe a bit foolish.
When I tried to create a database and Visual Studio suggested the name of the SQL Server it gave me my Windows username and since it's actually the name of the server I went for it.
In reality it actually was my Windows username + \SQLEXPRESS. If you didn't change any settings this is probably yours too. If it works, stop reading; this is my answer. If it doesn't work maybe the name is different.
If, like me, you only had this problem in Visual Studio to check what is yours follow these steps:
Open SQL Server Management Studioicon.
If you don't see your server (docked to the left by default) press F8 or go to View -> Object Explorer.
Right click on the name of the server and choose Properties (The last item)
At the bottom left you can see your server's actual name under "Server" (not Connection, but above it).
This is the name of the server and this is what you should attempt to connect to! not what Visual Studio suggests!
One more thing to check is that you have spelled the named instance correctly!
This article is very helpful in troubleshooting connection problems: How to Troubleshoot Connecting to the SQL Server Database Engine
In my case the database was running on non standard port. Check that the port you are connecting is the same as the port the database is running on. If there are more instances of SQL server, check the correct one.
All you need to do is open the relevant port on the server's firewall.
Having problems connecting to SQL Server?
Try disconnecting firewall.
If you can connect with firewall disconnected, may be you miss some input rules like "sql service broker", add this input rules to your firewall:
"SQL ADMIN CONNECTION" TCP PORT 1434
"SQL ADMIN CONNECTION" UDP PORT 1434
"SQL ANALYSIS SERVICE" TCP PORT 2383
"SQL BROWSE ANALYSIS SERVICE" TCP PORT 2382
"SQL DEBUGGER/RPC" TCP PORT 135
"SQL SERVER" TCP PORT 1433 and others if you have dinamic ports
"SQL SERVICE BROKER" TCP PORT 4022
Thanks again for answering my question. I have searched thoroughly the forum for possible answers but I could not find any success. I am trying to connect my SQL SERVER database to MATLAB. I have created an ODBC connection but its telling me the following the message :
{Microsoft][ODBC Driver Manager] Invalid String or Buffer Length. I heard that there might be issues with 64b version with some database, so I decided to change the IPALL port to 1433 on SQL configuration, note that here I have only client protocols under SQL NATIVE CLIENT configuration 32b, so i dont have the IPALL section, just TCP/IP with 1433, which is already correct. I am using a windows authentification.
So I decided to use a JDBC to see if it works, I did modified the txt files, classpath.txt and librarypath. Then I configured the JDBC in the matlab but I am getting :
The TCP/IP connection to the host localhost, port 1433 has failed. Error: "null. Verify the connection properties. Make sure that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port. Make sure that TCP connections to the port are not blocked by a firewall"
I dont know how to make this connection work, could you please help me? I am a rookie.
Note that my database is local, everything is local, my sql server have some tables which i want to get on MATLAB through ODBC or JDBC. I have created ODBC sources. As said earlier, I dont have any kind of SQL server per se in the config, the TCP/IP is only under client protocols under SQL Native Client 11
Hope its clear for you and thanks in advance.
S.
I had the same problem with 64bit version of windows. I tried windows 32b and it works now.
you can also watch this short clip on how to configure ODBC connection:
www.youtube.com/watch?v=DqbEHG2oAHg
A client of mine gave me a server name which is fully qualified [servername].somedomain.net
to try to connect to their SQL Server instance over VPN.
So I tried, using the username and password they gave me. No luck. I can ping it but cannot connect, I get the error that the username and password is incorrect.
So I log onto the actual server, verify that my login is in security and has rights and it appears there. Workgroup\mylogin and it appears that workgroup\ actually is the same as somedomain.net\mylogin. Because when I try to add somedomain.net\mylogin, it resorts to saying that it's already added which is workgroup\mylogin.
Not sure what else to check here. I gave myself sysadmin role in SQL Server. I can ping the server's IP.
I looked at how they are authenticating me and they have my user in SQL Server set up to use Windows Auth. Well, the error I get is that it cannot trust cross domain when trying to use windows auth when I try to connect locally here in my management studio. I'm connected tot their VPN so what could be the problem?
They're not available right now to try to troubleshoot it and I'm just curious what else I might try to try and resolve this on my own if I can.
Basically, when you failed to connect to your SQL Server, the issue could be:
Network issue,
SQL Server configuration issue.
Firewall issue
Client driver issue
Application configuration issue.
Authentication and logon issue.
Step 1: Network issue
You might be able to make local connection without a working network, but that's a special case. For remote connection, a stable network is required. The first thing to trouble shoot SQL connectivity issues is to make sure the network we rely on is workable and stable. Please run the following commands:
ping -a (use -4 and -6 for IPv4 and IPv6 specifically)
ping -a
nslookup (type your local and remote machine name and IP address multiple times)
Be careful to see any mismatch on the returned results. If you are not able to ping your target machine, it has high chance that either the network is broken or the target machine is not running. It's possible the target machine is behind a firewall and the firewall blocks the packets sent by ping, though. Windows firewall does not block ping (ECHO) packet by default. The correctness of DNS configuration on the network is vital to SQL connection. Wrong DNS entry could cause of all sorts of connectivity issue later. See this link for example, "Cannot Generate SSPI Context" error message, Poisoned DNS.
Step 2: SQL Server configuration issue
You need to make sure the target SQL Server is running and is listening on appropriate protocols. You can use SQL Server Configuration Manager (SCM) to enable protocols on the server machine. SQL Server supports Shared Memory, Named Pipes, and TCP protocols (and VIA which needs special hardware and is rarely used). For remote connection, NP and/or TCP protocols must be enabled. Once you enabled protocols in SCM, please make sure restart the SQL Server.
You can open errorlog file to see if the server is successfully listening on any of the protocol. The location of errorlog file is usually under:
%ProgramFile%Microsoft SQL Server/MSSQLxx.xxx/MSSQL/Log
If the target SQL instance is a named instance, you also need to make sure SQL Browser is running on the target machine. If you are not able to access the remote SQL Server, please ask your admin to make sure all these happen.
Step 3: Firewall issue
A firewall on the SQL Server machine (or anywhere between client and server) could block SQL connection request. An easy way to isolate if this is a firewall issue is to turn off firewall for a short time if you can. Long term solution is to put exception for SQL Server and SQL Browser.
For NP protocol, please make sure file sharing is in firewall exception list. Both file sharing and NP use SMB protocol underneath.
For TCP protocol, you need put the TCP port on which the SQL Server listens on into exception.
For SQL Browser, please put UDP port 1434 into exception.
Meanwhile, you can put sqlservr.exe and sqlbrowser.exe into exception as well, but this is not recommended. IPSec between machines that we are not trusted could also block some packets. Note that firewall should never be an issue for local connections.
Step 4: Client driver issue
At this stage, you can test your connection using some tools. The tests need to be done on client machine for sure.
First try:
telnet
You should be able to telnet to the SQL server TCP port if TCP is enabled. Otherwise, go back to check steps 1-3. Then, use OSQL, SQLCMD, and SQL Management Studio to test sql connections. If you don't have those tools, please download SQL Express from Microsoft and you can get those tools for free.
OSQL (the one shipped with SQL Server 2000) uses MDAC.
OSQL (the one shipped with SQL Server 2005 & 2008) uses SNAC ODBC.
SQLCMD (shipped with SQL Server 2005 & 2008) uses SNAC OLEDB.
SQL Management Studio (shipped with SQL Server 2005 & 2008) uses SQLClient.
Possilbe command use be:
osql -E -SYour_target_machine\Your_instance for Windows Auth
osql -Uyour_user -SYour_target_machine\Your_instance for SQL Auth
SQLCMD also applies here. In addition, you can use “-Stcp:Your_target_machine, Tcp_port” for TCP, “-Snp:Your_target_machine\Your_instance” for NP, and “-Slpc:Your_target_machine\Your_instance” for Shared Memory. You would know if it fails for all protocols or just some specific procotols.
At this stage, you should not see general error message such as error 26 and error 40 anymore. If you are using NP and you still see error 40 (Named Pipes Provider: Could not open a connection to SQL Server), please try the following steps:
a) Open a file share on your server machine.
b) Run “net view \your_target_machine” and “net use \your_target_machine\your_share” (You can try Map Network Drive from Windows Explorer as well)
If you get failure in b), it's very likely you have OS/Network configuration issue, which is not SQL Server specific. Please search on internet to resolve this issue first.
You can try connection using both Windows Authentication and SQL Authentication. If the tests with all tools failed, there is a good chance that steps 1-3 were not set correctly, unless the failure is logon-related then you can look at step 6.
If you succeeds with some of the tools, but fails with other tools, it's probably a driver issue. You can post a question on our forum and give us the details.
You can also use “\windows\system32\odbcad32.exe” (which ships with Windows) to test connection by adding new DSN for various drivers, but that's for ODBC only.
Step 5: Application issue
If you succeed with steps 1-4 but still see failure in your application, it's likely a configuration issue in your application. Think about couple of possible issues here.
a) Is your application running under the same account with the account you did tests in step 4? If not, you might want to try testing in step 4 under that account or change to a workable service account for your application if possible.
b) Which SQL driver does your app use?
c) What's your connection string? Is the connection string compatible to your driver? Please check http://www.connectionstrings.com/ for reference.
Step 6: Authentication and logon issue
This is probably the most difficult part for sql connectivity issues. It's often related to the configuration on your network, your OS and your SQL Server database. There is no simple solution for this, and we have to solve it case by case. There are already several blogs in sql_protocols talking about some special cases and you can check them see if any of them applies to your case. Apart from that, things to keep in mind:
a) If you use SQL auth, mixed authentication must be enabled. Check this page for reference http://msdn.microsoft.com/en-us/library/ms188670.aspx
b) Make sure your login account has access permission on the database you used during login ("Initial Catalog" in OLEDB).
c) Check the eventlog on your system see if there is more information
Reference: http://blogs.msdn.com/b/sql_protocols/archive/2008/04/30/steps-to-troubleshoot-connectivity-issues.aspx
Sorry for this wall of text, i hope that something from here can help you solve your issue!
Regards.
If you want to access that server you are going to need a domain account from that domain or use SQL authentication. I would recommend just using SQL authentication - it's a lot more straight forward - if they allow it.
I had the same problem, other machines could connect to sql server but one computer was not connecting and displaying the error "a network related or instance specific error...", the problem was solved when I changed the network protocol in the login window of SSMS, in advanced options from TCP/IP to Named Pipes. Please see the below screenshots.
Please note that you should be on the same domain, and your credentials should be valid on the server.
I am trying to connect to a remote SQL server. I would like to know the proper way to connect to the server. TCP/IP protocol is enabled. I am trying this way:
#"Server=myserver.com\SQLEXPRESS; Database=mydatabase; User ID=user; password=pass"
I am using myserver.com to connect to the server via RDP and I can connect without any problems, but when I am using the combination above to connect
to the SQL server via my code, it says that the server can't be found or does not exist.
Am I doing something wrong?
May I introduce you to http://www.connectionstrings.com whenever I have to manually create a connection string that's my first port of call. I can tell you right now that you can't do SQLExpress from a remote client (at least not the last time I checked). But here is the page for SQL Server connection strings. If it works, then it'll be there
Edit
It looks like you can connect remotely. It's just not configured that way out of the box