I am trying to port a web api that acts as a front-end for an SQL Server database. The web api works fine under Windows and when deployed to IIS, works from .Net Core on Windows, but gives a connection error when ran from within OSX or Linux.
The connection string that worked from within Visual Studio in Windows was
connectionString="data source=A\B;initial catalog=C;
persist security info=True;user id=X; password=Y;
MultipleActiveResultSets=True;App=EntityFramework"
providerName="System.Data.SqlClient"
which is then translated into the connection string for the .Net core variant as:
Server=A\B;Database=C;user id=X;password=Y;
The project compiles fine, even works under .Net core in Windows, but crashes when run from a *nix machine.
The error is:
Unhandled Exception: System.Data.SqlClient.SqlException:
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: TCP
Provider, error: 35 - An internal exception was caught) --->
System.AggregateException: One or more errors occurred. (No such device
or address) --->
System.Net.Internals.SocketExceptionFactory+ExtendedSocketException: No
such device or address
I can ping the address, but I guess the combination of valid address (A) and server instance (B) does not work with a simple slash under *nix.
Server=A\B;Database=C;user id=X;password=Y;
says that you are accessing to B instance on a Windows machine whose Netbios name is A. Probably the windows machine where it worked was "A" itself.
For a remote connection though there are things that you should have done:
The SQL server instance should be set to allow remote connections.
The port on SQL server listens to must be enabled for access on firewall.
Instead of Netbios name, it is better to use IP address, along with port number if it is not the default port (1433).
You may start trying (where 1.2.3.4 is the windows machine's IP):
1.2.3.4\B;Database=C;uid=X;pwd=Y
For a detailed installation and setup of SQL Express on host PC, enabling for remote access and then accessing from remote computer, you may watch my short video series. Those videos were about installation of my application but most of it contains installing MS SQL server and accessing from remote location. It is a 4 parts series and here is the link to first part:
AccuSQL Installation 1/4
Related
I'm attempting to connect to a test Database on a Parallels VM on Mac using Azure Data Studio, but I'm getting the standard, generic connection error:
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: TCP Provider, error: 40 - Could
not open a connection to SQL Server)
Steps I've taken so far to open the connection include:
Opening port 1433 through windows firewall
Ensuring remote connections are allowed on the SQL instance
Setting the TCP/IP Protocol to 5171 for IPAll
Running SQL Server and SQL Browser Instances
Adding a rule to windows firewall for sqlservr.exe to allow all connections
Enabling the SA account and adding a password (password is correct - I've double checked in SSMS on the VM)
I'm able to connect from the windows VM but not the Mac.
My connection string is below (IP is correct, again I've double checked):
Is there a step I've missed or some extra config that I need to do on the VM itself maybe? Or maybe the connection string isn't quite right? I've also tried using the Machine Alias to connect to the instance (SQLEXPRESS) - but still no joy. Anyone know what the problem might be because it's driving me crazy and I can see that other devs have made it work, so I know it's possible. My version of Parallels is Desktop 15, I don't know if that makes a difference or not?
Ok so turns out I needed to open the IPAll port I had set for the TCP/IP Config which in my case was 5171 as well as adding a rule to allow SQL Server Browser to connect to the internet.
For those of whom the above method doesn't work, try Bridged Network instead of Shared Networking in the Network settings and replace the old IP address with the new one.
I am able to connect to Microsoft SQL Server (in Parallels Desktop 16) using Visual Studio Code in macOS Big Sur.
I have a small application that uses a SQL-Server express 2005 database located on a remote machine. This has worked for years. I've not only been able to access it via the application, but also on the development machine. The other day I came in to the server (windows 7 machine) shut down from a power outage. Since then I have not been able to access the database and receive an error 26. I have checked the firewall and it does indeed have the exception for sqlbrowser and UDP 1434 set. I also checked Configuration Manager and SQL Server (SQLEXPRESS) and SQL Server Browser are both running. (Even did a restart on both)
Client Protocols are enabled for Shared Memory, TCP/IP and Named Pipes.
Here is where it gets strange (At least for me). Both the development machine and the machine that uses the application that works with the database were both set to Obtain IP Address. If I set these to a static address they are then able to access the database without issues. I would like to not have to set static IP's and get things running the way they have for the past couple of years. Does this shed any light on what I might need to check to see why I can no longer access this server without a static IP on the remote machines?
The server is 2007 pro along with the development machine. The remote machine that uses the application is Windows 10 pro.
I should also state that I can browse the network and access normal shares via windows network with and without the static ip from both machines.
EDIT: The exact message I get when I don't use a static ip is:
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: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) (Microsoft SQL Server)
I get this error even when trying to connect using Microsoft SQL Server Management Studio Express.
After many installations I learned that opening the SQL Server port in the firewall works always when using the default instance, but with named instances and SQL Browser opening the ports some times doesn't prevent the firewall for blocking connections, specially in small environments that doesn't have a proper server like the one you describe (I think that it's related to the dynamic port feature that SQL Server use by default with named instances, but I'm not sure).
When I have to use named instances instead of opening the ports I create rules for the programs themselves and it has worked fine until now. Create two rules using New rule > Programs > This program path, one for:
C:\Program Files\Microsoft SQL Server\90\Shared\sqlbrowser.exe
and other for:
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe (maybe this location is a bit different when using the SQLEXPRESS instance).
I usually create the rules only for private network locations, but maybe you should create the rules for all locations just to be sure (and if this works, try unchecking public locations from the rules).
For future installations note that you can configure Express editions to use the default instance MSSQLSERVER at install time (and only at install time), with that option you just open port 1433 and you are done.
I have an ASP.NET Core 1.1 Web API which runs in a Docker container on Ubuntu and connects out to a SQL Server database (SQL Server 2012 SP3) on a Windows server. This works in 3 out of 4 of out environments, but in one environment it cannot connect to the SQL Server and I am trying to troubleshoot it.
The error is:
Unhandled Exception: System.Data.SqlClient.SqlException: 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: TCP Provider, error: 25 - Connection string is not valid)
The SQL Server has an instance name: SQLSERVER1\APPS. From the Linux server I can ping the server SQLSERVER1 and telnet to SQLSERVER1 1372 (1372 is the port for the APPS instance: so network connectivity is there.
The only space I can see for the problem to occur is how .NET Core translates the instance name to a port number. Does anyone know how this is done and whether it is configurable on the client machine?
Remote named instance listening port discovery relies SQL Server Browser Service and protocol. As you cannot leverage this for your Linux docker image, I suggest you connect by explicitly specifying the port and omitting the instance name: "server=tcp:SQLSERVER1,1372;database=...;...":
The name or network address of the instance of SQL Server to which to connect. The port number can be specified after the server name: server=tcp:servername, portnumber
BTW if you live the instance name it should make no difference whatsoever after you explicitly specify the port.
PS. After reading again the question, the issue is related but different cause. Normally the Linux container can discover the Windows SQL Server, as the Browser service is probably up and running (proof that 3 envs. it works). In the 4th environment it means something blocks the discovery. Either the Browser service is stopped, or the browser discovery protocol listening port is blocked in the FW (UDP 1433), or perhaps the UDP packet (or the response!) is lost somewhere between the container and the server. You can investigate and find the root cause, but, you can also just ignore the problem and work around the issue by... specifying the port explicitly, just as I showed.
I am trying to connect to an MSSQL server from a C# ASP.Net core application running in OSX. The MSSQL is on a separate machine which firewall is configured to let connections via TCP to port 1433 and via UDP to port 1434.
The connection string I am using is:
Server=IP\SQLEXPRESS;Database=DB_NAME;user id=****;password=*****
What is very confusing at this point is that the very same connection string works flawlessly from Windows and both Visual Studio and Visual Studio Code. The moment I reboot in my OSX, then VS Code opens the project but raises the dreaded
System.Data.SqlClient.SqlException: 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: TCP Provider,
error: 40 - Could not open a connection to SQL Server)
exception. I have no idea what to do, as this code should work. What does the OSX implementation of the SQL Server connector do that is so different?
As Giuseppe said, you need to use IP,port. Named instances can run on various ports and Windows clients (i.e. SQL Management Studio) detects port by asking SQL Browser service.
In you case, you should open SQL Configuration Manager, Go to SQL Server Network Configution -> Protocols for SQLExpress (or whatever is name of the instance) -> TCP/IP (right click) -> Properties -> Ip Adresses tab, scroll to bottom and see (and/or) set the current port.
Apparently the *nix implementation of the UseSQLServer method does not support instance names. Therefore IP,port is the way to go.
I developed a .net application that depends on a sql server database, the database was on the local machine used for development of the application.
When I moved the database to a remote machine and changed the connection string I got the following error:
An error has occurred while establishing a connection to the server when connecting to SQL server 2005, this failure may be caused by the fact that under default settings SQL server does not allow remote connection. ( provider: Named Pipes Provider, error: 40 – could not open a connection to SQL server. )
This error occurs only from XP machines but it works fine from Win. 7 Machines with the same connection string:
connectionString="Data Source=ot;Initial Catalog=sp_warehouse;User ID=fu;Password=bar"
I tried the following to troubleshoot the problem:
- Disabled Named Pipes service from the server.
- Added an exception in the server firewall for the SQL Server port 1433
- Disabled the firewall on the server completely
- Added this parameter in the connection string: Network Library=DBMSSOCN;Persist Security Info=True
Each time I try something I get the same result, win. 7 machines work fine but XP machines don't.
Note: There's another application works from XP machines that uses another database on the same SQL Server and it's working fine.
Make sure the SQL Browser is enabled and running on your remote machine. You'll probably want to leave named pipes enabled.