In my job we have several servers with SQL Servers. Every one has several instances. Access to any was clear... until today. I wrote app in WPF which use connection string as this
Data Source=server02\system; Initial Catalog=*****; User Id=*****; Password=*****;
Under every * hides char [a-zA-Z], digit or special char.
When I run my app from my coputer location everything works, but if I run it from server02 location (//server02/apps/app.exe) it fails.
Exception:
SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified
And the question is... How to fix it? Why the hell server connected to our LAN doesn't recognize his own localdb?!
Enable Named Pipes connections from your SQL Server instance.
For this just go to SQL Server Configuration Manager to enable Named Pipes.
Related
I have a program with a dataset on a windows form program that connect to a database. On the deployed server everything works ok. Then I added a table to the sql table and to the same dataset that worked in the past. It works on my local machine, but on the deployed machine it does not work. I had this problem once before and when I added a table to the dataset it added a hard coded path to the database. I've checked for this and this is not the problem. Anybody know what else I can check.
The program give the following error when opening the new table,
System.Data.SqlClient.SqlException (0x80131904): 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) --->
I have two connections strings in my program. One for the local server and one for the deployed server. I simply add or remove the one for "ClubConnectionString1" in my app.config file on the deployed machine. When I added the table in the dataset it choice the wrong one, and therefore when deployed it couldn't connect.
To fix the problem I manually searched for "ClubConnectionString1" in the clubdata.Designer.cs of the clubdata.xsd file, and removed the 1 from ClubConnectionString1. That fixed the problem.
I have a simple windows service that we have used for years. We developed it in-house, but no one has touched it for years. It updates a couple tables in a SQL database located on the same server. I installed it on a virtual server, and it appears to be running, but is not updating the SQL database.
I believe it connects to the database using an Alias set up in CLICONFG. It is set using a Named Pipes connection pointing to the local SQL EXPRESS database.
It is running properly on a server with a default instance of SQL EXPRESS installed. The only difference I can find is this current server has a Named Instance (.\SQLEXPRESS). However, I have had it running successfully on other servers with a Named instance rather than a default instance, but I can't seem to get this one to work.
I have searched and searched and have been unable to figure out what is wrong.
I've checked for possible permissions issues in SQL, and everything seems to be in order with the login I have chosen for the service.
Thanks!
Thanks everyone for your suggestions. I figured it out!
Turns out it was connecting to SQL through a Named Pipes Connection setup in cliconfg.
I already had a Named Pipes Connection setup with our standard alias....and the pipe specifying the SQL Named Instance....that wasn't working for this server.
The service was expecting a default instance. The service had worked properly before w/a Named Instance w/out modifying our standard Named Pipes configuration, but that was a 32-bit windows server. This time, on a 64-bit windows server, it wasn't working.
So....
I used ProcMon to determine what it was looking for...then added a second Named Pipes connection named "(local)" instead of our standard alias. I set the pipe up exactly the same as our other connection. I left our standard Named Pipes Connection there as well with our standard alias.
Rebooted and it worked!
We're attempting to deploy an existing SQL Server/SSRS configuration to a new set of hardware. SSRS is running on the same server as the SQL Server database we're trying to get reports from.
Whenever we attempt to test any of the reports, we receive the error:
An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'sqlConnection'. (rsErrorOpeningConnection)
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
The Windows user has full rights to the server.
The logins all appear to exist.
TCP is running.
Named instances are fine.
SQL Browser Service is running
"sqlcmd -L" shows the database server listed
I'm at a complete loss.
Create a udl file, if it connects then the problem is the code / application, if it does not connect, then it's your firewall, connections string, dll library, service you are running IIS under not having the right permissions etc etc. Well the important thing here is probably the connection string. Do the following: create an empty text file and rename it "myconnection.udl". Now double click on the file and it will launch an applet. You can configuer the connection to your database and test it. (it will pick up registered connection libraries etc). If it gives OK, then open the udl file in notepad, you will see the correct connection string. Paste to your app connection settings. UDL files are generally misunderstood. They are simply a text file that holds the connection settings. They then call the connection dll. If the udl file works then you have a correct connection string 100%
We created a new report and deployed it and it just worked. After some investigation, the report that I had been asked to use as a test initially has a parameter that defaults to connect to a completely different SQL Server which the new environment cannot, and should not see. All the other reports are working.
My guess is that we actually corrected the problem early on when we modified the service credentials, but by then we had fallen into a loop of testing against what turned out to be a bugged report.
TLDR: There was a bug in the report we were testing against. We had already corrected the problem and didn't even realize it because, apparently, we're idiots.
I tried to login to a remote server and I saw the error given at the link -
http://www.microsoft.com/products/ee/transform.aspx?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=2
Message says -
Message: An error has occurred while establishing a connection to the server. When connecting to SQL Server, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (.Net SqlClient Data Provider)
Which is followed by -
Explanation
SQL Server did not respond to the client request because the server is probably not started.
Arent the message and explanation contradicting each other ? Which one is the correct reason for the problem ? How do i find out the REAL source of the problem ?
They don't contradict each other. They just give different possible reasons:
SQL Server doesn't allow remote connections
SQL Server is not started
To fix it, make sure that SQL Server allows remote connections and is started.
Allowing remote connections can be done in the "SQL Server Configuration Manager":
Start that program on the server on which SQL server is installed.
Navigate to "SQL Server Network Configuration" -> "Protocols for "
Double click on the connection type - e.g. Named Pipes - and set "Enabled" to "Yes".
If you are enabling TCP/IP, make sure to also enable each individual IP address on the second tab.
See this blog post for more info.
Thee program you are using is unable to find SQL server on the port/address it expects to.
This is likely either because it is misconfigured, or because SQL server is stopped.
I suggest you open a desktop login to the machine in question, and see if SQL server is running.
There are other potential causes for this problem, as well: network problems, for example.
When setting up a system that requires a remote computer to access SQL 2008 stored on another computer in the same domain, I'm running into the following error:
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.
When I installed SQL Server, I was sure I set up the system just so. How can I troubleshoot this?
I appreciate this thread is old now and already has an accepted answer, but I found a slightly different solution with regards to this issue that others may find useful. From reading this issue description I found that there were two SQL Server services in the standard Windows Local Services control panel: MSSQLSERVER and SQLEXPRESS (see below).
I found that SQLEXPRESS was running, but MSSQLSERVER was not. So I simply started that service, and I was able to connect to SQL Server again.
A couple of things to try...
check the Configuration settings to ensure that the TCP protocol is enabled.
try accessing the remote server via IP instead of the server name, this has worked for me in the past (oddly).
I'm assuming its running on the default port, if it isnt then you will need to specify the port number after the server-name / ip separated by a comma:
sql-server-name,{port}
Look at the name of the SQL server instance and make sure it is what you are using to connect to it. Also, look at the SQL Server Network Configuration under Configuration Tools. I worte an article about a very similar problem (if not the same) here:
Having had this a few times even with named pipes the first thing I always try is pre-pending the server name before the named instance; so SERVER\namedinstance. You can manually overwrite the dropdown values in the connect . So ideally in the setup it should have a brief tip below the named instance box like Enter SERVER\namedinstance. Although knowing MS if you entered this you'd probably end up with SERVER\SERVER\namedinstance...!
You can also use the browse option (bottom of server dropdown) and if you're lucky it may be in the 2nd tab (Network Servers) - even if it's a local install.
The program you are running needs to be running under an account which has access to the network (and depending on protocol chosen, may need access to the SQL Server by role or whatever). This error indicates that it is not finding the server on the network by name or IP.
The most common case I have seen this is when you have a web app running under a local account which does not have network access attempting to access SQL Server on another machine.
If you have access to the server that SQL Server is running on, you can try:
-Opening SQL Server Configuration Manager
-In the left pane, click 'SQL Server Network Configuration' and then 'Protocols for [instance name, possibly SQLEXPRESS]'
-Right click TCP/IP again and you'll see the port used. Mine was listed under IPAll/TCP Dynamic Port.
-In SQL Server Management studio add the port name to your connection string as follows:
if you were connecting to:
MYSERVER\SQLEXPRESS
the port is specified as
MYSERVER,2071\SQLEXPRESS