Develop Reference

How applications are able to find a SQL Server DB - one VM to another (setup or configuration question)

In my company we have 3 virtual machines (application, business, DB).
Been trying to understand how our software app running in my machine which uses a simple text file with connection string is able to communicate to another server like the database server to connect to MS SQL installed there.
If I login to Business server and run a simple powershell to query the SQL db, it is able to connect as well.
My question is, how does the visibility of MS SQL Server (running on our DB Server/vm) available to the Application and Business servers? Was it done by installing some components to application/business server and making bits of configuration to be able talk to the SQL server from another VM? What's normally the setup here?
Sorry, you might be wondering why I'm asking you guys and not the developers in my team, but they don't know either, because they run the client app and it connects to the DB using the connection string. The DBA/Infrastructure guys were the ones who did some setup but can't be bothered or won't want to be bothered.
Thanks

You should specify more details in the next format :
Language, Tools used.
Version and name of framework.
Db version.
VM Machine version and type. (Oracle, VMWare, etc)
The first thing to check it's your connection outside your app and inside each VM.
If you reach from the VM to the Database allocated in the external server that means the infra team has made their job.
If not, your vm setup has to be in a net configuration that allows your vm to have access or reach the net where you're central server with the db it's allocated.
Take a look at : https://www.cloudsavvyit.com/3477/which-type-of-networking-should-you-use-for-your-virtual-machine/
If the second one it's the case, this it's not a Developer task. it cames mores from the Infra side and you should scalate the issue with your pm to the corresponding department.
Those should be your first items to work on. Best!.

SQL Server connection errors when moving .net app to new server

I have a number of .NET web apps on a Server 2008 machine that I'm trying to migrate to a Server 2019 machine, and some of them are giving me problems connecting to SQL Server 2016 instance on another server after moving them.
The error I get is
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: SQL Network Interfaces, error: 25 - Connection string is not valid) ---> System.ComponentModel.Win32Exception (87): The parameter is incorrect
This one is a .NET Core 2.2 web app. (.net core 2.2 server package installed on server) the connection string is like
"Server=mysqlserver\myinstance,3050;Database=Idea;Trusted_Connection=True;"
and is using Entity Framework/DbContext to connect.
The app in IIS has an app pool created for this app, set up the same as it was running on the old server: No Managed Code, Identity set as a domain user "domain\user".
Ping from new app server to database server works. Running SSMS as the domain user on the new server connects to the database fine and can view data through management studio.
So I don't know if there is something different in Server 2019 about the way it's trying to connect to SQL Server or what? I've been banging my head on this for a few days now. .NET 4.0 apps are also having the same errors trying to connect to other databases on this same instance.
The weird thing, is some other apps work fine, connecting to a different SQL 2016 instance on a different server, but they are also different .net versions, like older .NET 4.0 web apps, but they are running as app pools with different domain accounts for each app fine.
It seems all .NET Core or .net 4.0 web apps on this server are having trouble connecting to this one database instance from this server, but back on the old web app server they work fine.
Any ideas of anything else I can check?
Edit: I found the error is actually when connecting to a new SQL Server, even from the old app server it still gets the same error. I have 2 connections in this application, so I thought it was the first one, but it was actually the 2nd one. So it's something more to do with the new SQL server instance. Again, connections from SSMS work fine with this user, but not from the web app.
Edit2: After more testing, it's definitely something to do if there is Server 2019 in the mix. From 2019 app server to 2019 db server fails. From 2008 app server to 2019 db server fails. From 2019 app server to 2016 db server fails. From 2008 app server to 2016 db server succeeds.
Edit 3: I feel like I'm going crazy here. One of the apps, I tried to change ASPNETCORE_ENVIRONMENT to Development so that I could see more detailed errors on screen, so I set the appsettings.Development.json to the exact same as the appsettings.Production.json and then the connection works! Switching it back to production it gets the error again. The entire file is the exact same text. How does that even make any sense? I even tried explicitly setting the environment variable to Production instead of letting it just pick it up as the default.
Edit 4: I've solved half of the problems I've been having now.
For whatever reason, the connection string that I copied from one of the spreadsheets in the beginning had crazy hidden characters in it so that’s why it was saying the sql server didn’t exist.
I can’t see them at all in any editor and only found it by VS Code compare saying the line was different but not seeing any difference I broke it into chunks and found the spot. We found when we opened it in WordPad, that was the only place that would show it, see below.

I'm fairly sure the solution is to remove the instance name from the connection string...
"Server=mysqlserver,3050;Database=Idea;Trusted_Connection=True;"
Refer to these questions question1 & question2
"It's not necessary to specify an instance name when specifying the port."

Problem was due to hidden characters in the connection string. See my Edit 4. Other problems leftover were unrelated.

Try to create an user in the database using the same AppPool name that you used to configure your application in IIS.
Here's a "how to" create the user in the database:
https://engram404.net/grant-sql-permissions-to-iis-apppool-user/
It worked for me.
Otherwise here's an "why" it happends:
You're telling in your connectionString that it will be using an trusted connection "Trusted_Connection=True;"
If you do not want to create the user as described earlier, you should remove the Trusted_Connection=True; and use your connection string like this:
Server=mysqlserver\myinstance,3050;Database=Idea;User Id=SetYourUser;Password=SetYourPassword"

I know you happened to solve this, but still..
You can't connect to a MySQL database with System.Data.SqlClient - It is configured for an SQL database, not MySQL
You can find the MySQL Data Connector Here. (You can otherwise download it from Nuget)
If you downloaded it from Nuget, then skip this step.
After downloading the package, you can add it as a reference in your project, by right-clicking the References item in the Solution Explorer, then click Add Reference... - The Reference Manager window will then open. Click the Browse item in the left-menu, then click the Browse button, and navigate to the directory of which the package was saved.
Now, after successfully downloading and installing the package, add this line to your code:
using MySql.Data.MySqlClient;
The correct syntax for connecting to your MySQL Database, using MySql.Data.MySqlClient;, would be:
string connectionInfo = #"Server=localhost;Database=your_database;User ID=root;Password=123456";
So, overall, your code would look like:
using(MySqlConnection con = new MySqlConnection(connectionInfo))
{
con.Open();
MessageBox.Show("Successful Connection!");
}
(Code / part of answer is derived from here.)
I hope I could help anyone else with this problem :)

Connection to remote SQL server breaks when upgrading web server to .net framework 4.6.1

We're currently working on updating our asp.net web application (hosted on IIS 7.5) from .net framework v4.5 to v4.6.1. On small lower environments/local development in which SQL server runs on the same box as IIS, this update works fine and does not break anything. However, once we update our web servers in our test environments which host SQL server remotely from our web servers, our application can no longer establish a connection to the database. We receive this error:
Connection Timeout Expired. The timeout period elapsed while attempting to
consume the pre-login handshake acknowledgement. This could be because the
pre-login handshake failed or the server was unable to respond back in time.
The SQL server is running with CLR version v4.0.30319.
We use Entity Framework version 6.0.0.0 for data access, and the connection strings all use integrated security. Do we need to update the boxes hosting SQL server to .net 4.6.1 also? I don't see why that would be necessary for our app to establish a connection to the database, but I've been unable to find any guidance on MSDN about this.
EDIT:
After this breakage, we downgraded our web servers back to .net v4.5 and we were able to re-establish a connection to SQL server. re-upgrading to v4.6.1 caused the breakage yet again. Therefore, we are relatively sure that the upgrade is the issue, and not a change in application code and/or IIS settings.

Update - so it looks like we've found (at the least the solution to) the problem. Turns out -- as the exception suggested -- that by increasing the connection timeout property on our connection string (default is 15 seconds, we set it to 60 seconds), we were able to make a connection to our database through our web app. However, opening this connection takes a prohibitively long time, so we started looking for solutions to make our connection open faster. We've discovered that we have Netbios over TCP/IP enabled on our database server, and that by opening up UDP ports (137, 138) on our network for Netbios access, we were able to open connections to the database way faster, timing at <1 second instead of >15 seconds.
We're still not sure why the .net upgrade exposed this problem. By testing with a UDL file, we were able to establish that the network connectivity to our database performs about the same on our web servers on .net 4.5 as on our web servers on .net 4.6.1. So it seems as if our connections were opening so slowly that we were already very close to timing out, and some sort of extra logic/cruft in 4.6.1 put us over the edge. I'll update if we find more clarity on that.

The following article describes a new default connection string setting for SQL Server connections in .net 4.6.1.
https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/
This was to solve one problem in some environments, but also caused the issue you are experiencing in other environments.
Basically, you'll want to add the following your connection string:
TransparentNetworkIPResolution=False;

you might want to check the machine.config and web.config files in the windows\micorsoft.net\framework64\v######\config folders. each version of .NET runs on different config files. Since the same code is used in both environments, it must be from the config inherited from here. I am guessing that the 4.6.1 is set to default the connection string to localhost and since the SQL in local and dev are on the same server it is not an issue. You will probably find that the config in the .NET 4.5 version has a connection string defined beyond localhost.
if 4.5 and 4.61 are using the same config files, then make sure you define a default connection string to be used by the entity framework in that web.config.

First of all - this issue appears only when you're using Active Directory authentication.
I've managed dirty-fix: add your MSSQL server to your local (machine which can not connect to MSSQL server) hosts file (%windir%\system32\drivers\etc\hosts).
For example:
192.168.0.5 mssqlserver
It realy doesn't matter the name. It also works well if you have multiple SQL servers on one IP address (connecting through NAT).
This dirty-fix will also fix slow loading using SQL Management Studio issue.

WCF Service Problems

I'm having trouble setting up my WCF Service to an IIS server. The current setup I have is a WCF service written in C# that accesses an external database (located on a different server, different location than our IIS server) and an ASP.NET web site that consumes the service on our server, and uses it's methods to query, then display some data.
Before I uploaded the Service and website to our server, I tested it using the default setup done by Visual Studio. This test led to promising results, because when I let visual studio host the service (and whatever else it does in order to setup the environment for testing) and consume it with the website, everything went smoothly, and all of my queries went through flawlessly.
I can upload the service fine, consume it fine with the website, but I have problems when my service makes queries to the external database. I get an "underlying provider failed on open" error when an actual query is made. I've tried a few different things and I couldn't find an answer. For legal reasons , I'm not allowed to upload the code, but I think this problem is due to incorrect setup on the server.

Assuming that you're using Entity Framework, that problem almost always indicates that there is an issue establishing a connection to your database. Check your connection string and make sure that the server and instance names are correct, and that the user your service is running under has access to the database. If you're hosting in IIS, this would usually be a service account (e.g. NETWORK SERVICE) or local system account.

The issue ended up being the connection string in the end. On my local machine, the name of the server was resolved with the Hosts file, but the server had nowhere to resolve the name of the server mentioned in the connection string. This was causing the issue. This has been resolved by updating the server hosts file.

I've gotten this error on new installations of SQL Server, and I fixed it by enabling Named Pipes in SQL Server Configuration Manager. Could be the same issue you're having.

Oracle: Cannot connect from entity framework

I've an oracle server, already installed on a remote server.
I've installed oracle latest provider, to use them in visual studio with entity framework.
But when I'm trying to connect to the server, I got this exception:
ORA-12560: TNS:protocol adapter error.
I'm really new to the oracle world, and I cannot find what is the problem or even how to debug it.
I saw that listeners are ups, by doing a lsnrctl status I've my listener on the port 1521.
But, I saw that i've the security like this: "Security ON: Local OS Authentication", but since I've no common users between the server and the client, can it make somes troubles?
Should I have some specials rights on my user? In local, I can connect myself with the sqldeveloper tools.
Any help would be greatly appreciated
EDIT
Some more informations:
The server runs under windows, it has the OracleXETNSListener service started. I forgot to mention, but the server firewall is off.
Edit 2
I tried to download the oracle sql developer on my workstation, and I connected myself with exactly the same informations.(I just saw that in fact sql developer use a "base" connection instead of "TNS", which seems to be used by the EF?

I ended by using the devart connector: http://www.devart.com/dotconnect/oracle/
it worked for me directly in all mode(Direct or normal). If only I did tried it this morning, I will have loosed less time.

Are you using your tns names via AD or locally on your machine? If it's local then you'll need to make sure that you have the correct connection descriptors listed in the tns names file located in the default location - this depends on Oracle version.
There are known issues around entity framework and connecting to remote instances, but these can be overcome with a l

Using the Oracle Provider, your connection string should look something like this:
Data Source={serverAddress}/xe;User Id={UserName};Password={Password};
Example:
Data Source=localhost/xe;User Id=scott;Password=tiger
I suggest you to always mention the Oracle Instance Identifier (which in the Express Edition is always xe), so you don't have to rely on your tns config settings.