Develop Reference

Connection to Oracle database not working

I am currently working on a project with someone. We are connecting to a oracle Database using the NuGet Package Oracle.ManagedDataAccess.Core.
We are connecting using a connection string that looks like this:
"User Id={this._dbUser};Password={this._dbPassword};Data Source={this._dbServer};"
The Parameters we pass on are correct we checked multiple times.
At first I got a Connection Timed out error which we fixed by adding persist security info=false;Connection Timeout=120; to the connection string.
At first it seemed to be working but then we encountered a new error.
This time it was saying:
Oracle communication: Connection to server could not be established or connection string not parsed
(Might not be 100% accurate because I had to translate it from German to English)
We could not find a solution for this error but we discovered that the error only gets thrown when we run the code on my machine. His is doing totally fine and can connect without any problems.
Could it be that I have some settings set on my machine that would prevent me from accessing the Database?

Is connecting to a database using SqlConnection() AND a Connection string safe?

I am using the following code in conjunction with dapper ORM to connect to a database :
using (IDbConnection db = new SqlConnection(ConnectionString()))
{
return db.Query<object>(Sql).ToList();
}
The connection string contains database name and login information. I am wondering if while establishing connection to the database server, if any of that information could be visible to someone else.

If you mean in transit: you can force SQL Server to use encrypted connections - https://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx
If you mean in-process - the key parts are removed by default so they won't be trivially available to other code with the SqlConnection instance; this is related to the "Persist Security Info" parameter on SqlConnection's connection-string, which defaults to false. Basically, the .ConnectionString property does not expose the credentials once provided. Note that the string will still have existed in memory at some point, so someone with raw access to the process and memory analysis tools may still be able to obtain it; see https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring(v=vs.110).aspx
However, you could also just use Windows authentication via SSPI - this then just uses the app-domain's executing user identity info to connect. Same link as above, but see the "Integrated Security" connection-string parameter.

On the Local Computer: Yes, it would be possible to get access to the information
Over the Network DB Connections: Depends on DB, SQL Server supports SSL, but if you don't use that then you'd be exposing information in your traffic

This would entirely depend on where the connection is being established from and where the connection is being established to.
If either end is in the hands of someone for example, in a distributed client, then they will be able to get hold of the connection details. Typically however, a connection is established "behind the scenes", something like from a web server to a database. Because a connection established like this is all "server side", the connection string is never visible to the "client" of the application and is therefore generally perceived to be safe - of course it is still at the mercy of the infrastructure! :)
It's worth nothing that if this is something like a thick client running on a domain then using something like Windows credentials is an option and would be as secure as the account.

SQL Server problems to connect

I am developing a program with C# and WPF. I want the data to be stored in an SQL Server database. I made a connection string with the instance name in my PC, and that worked. But when I want to connect through the Internet with an IP address, I get some errors:
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. (TCP Provider,
error 0 - No connection could be made because the target machine
actively refused it.)
I enabled TCP/IP, allowed remote connection in SQL Configuration Manager, opened a port of 1433 in my firewall, but still I am getting this error.
My connection string is this:
String connString = #"Network Library=dbmssocn;
Network Address=127.0.0.1,1433;
Integrated security=SSPI;
Initial Catalog=db";
SqlConnection conn = new SqlConnection(connString);
conn.Open( );
Where is my mistake?

There is very slight error in your connection string and honestly I can't blame you for that as it is very weird way in which SQL Sever is behaving. I'm not sure if this error lies in connection provider side or SQL Server instance side. Name of Network Library that your application is using to connect to the SQL Server using dbmssocn(Win32 Winsock TCP/IP) should always be mentioned in capital letters. Though I didn't see any relevant MSDN documentation from MS to support my statement but it actually worked when I did so. Here is the connection string that you should be using to fix the error.
String connString = #"Network Library=DBMSSOCN;
Network Address=127.0.0.1,1433;
Integrated security=SSPI;
Initial Catalog=db";
Seriously, I got freaked out in reproducing your issue as instead of copying the connection string from your question I copied it from some other blog :). But all is well that ends well. I've also assumed that a database named "db" actually exists on the default (NOT named instance) instance of the sql server you are connecting to when typing this answer. If changing the casing of network library name in connection string doesn't help then double check that database "db" must exist for a sql server default instance to which you are connecting to. In case you are using a named instance of sql server in your installation then that instance name should also come in the connection string.

Configure your SQL Server to allow TCP/IP connections. Go to SQL Server Configuration Manager -> network then protocols for your SQL Server named instance -> TCP/IP.
See this image!

Can connect mysql database via navicate but cant from c# application

here is all info.
Step 1
Step 2- Error Msg
Step 3- connection String
I have tried without using port number but the problem is same. There is IP restrictions for remote login. but if it is because of IP restriction why am I able to connect with Navicat.
Code of C# where i'm getting error.

As per step 1 it seems the connection has been successfully established, but still you are unable to connect to the specific database. Check the name of the database or confirm that the database exists with the name supplied in the connection string. You can do that even by creating a connection from Navicat. If the database exists you will find it there.
Cheers

Maybe you should invoke mysqlcon.Open() before using mysqlcon.

Solving a timeout error for SQL query

I am getting this error:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
I know there are already guides out there to help solve this but they are not working for me. What am I missing or where should I add the code to these SQL statements in my C# program:
String sql = project1.Properties.Resources.myQueryData;
SqlDataAdapter sqlClearQuestDefects = new SqlDataAdapter(sql,
"Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa");
DataSet lPlanViewData = new DataSet();
sqlClearQuestDefects.Fill(lPlanViewData, "PlanViewData");
I am getting the timeout error at this line:
SqlDataAdapter sqlClearQuestDefects = new SqlDataAdapter(sql,
"Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa");

SqlDataAdapter adp = new SqlDataAdapter();
adp.SelectCommand.CommandTimeout = 0; // Set the Time out on the Command Object

You're trying to connect to a SQL Server, and it is taking longer than ADO.NET is willing to wait.
Try connecting to the same server, using the same username and password, using SQL Server Management Studio. If you get the same error, there is either something wrong with your connection string, the server you specify is not running, or you can't get to the server across the network from where you are (maybe you're on a public IP address trying to get in to an internal server name). I can't think of a scenario in which you'd enter the exact same server and credentials into SSMS and connect, then do the same in ADO.NET and fail.
If you're on a slow network, you can try increasing the timeout value. However, if a connection is going to happen at all, it should happen pretty quickly.
Take a look at both your SQL Native Client settings, and the SQL Server settings on the server. There is a section for allowed protocols; SQL can connect using a variety of protocols. Usually, you want TCP/IP for a server on the network, and Named Pipes for a server running on your own computer.
EDIT FROM YOUR COMMENT: Oh, that's normal; happens all the time. From time to time on a TCP network, packets "collide", or are "lost" in transmission. It's a known weakness of packet-switching technologies, which is managed by the TCP protocol itself in most cases. One case in which it isn't easily detected is when the initial request for a connection is lost in the shuffle. In that case, the server doesn't know there was a request, and the client didn't know their request wasn't received. So, all the client can do is give up.
To make your program more robust, all you have to do is expect a failure or two, and simply re-try your request. Here's a basic algorithm to do that:
SqlDataAdapter sqlClearQuestDefects;
short retries = 0;
while(true)
{
try
{
sqlClearQuestDefects = new SqlDataAdapter(sql, "Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa");
break;
}
catch(Exception)
{
retries++;
//will try a total of three times before giving up
if(retries >2) throw;
}
}

Since the exact command to increase connection time out wasn't mentioned in the other answers (of yet)- if you do determine a need to increase your connection time out, you would do so in your connection string as follows:
Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa; Connection Timeout=120
Where 120 = 120 seconds. Default is 20 or 30 as I recall.

This is probably a connection issue with your database, for example if you had the following connection string:
"Data Source=MyDatabaseServer...
Then you need to make sure that:
The machine MyDatabaseServer is connected to the network and is accessible from the machine you are running your application from (under the name "MyDatabaseServer")
The database server is running on MyDatabaseServer
The database server on MyDatabaseServer is configured to accept connections from remote machines
The firewall settings both on the local machine and MyDatabaseServer are correctly set up to allow SQL Server connections through
Your username / password etc... are correct
You can also try connecting to the given database instance using SQL Server Management Studio from the client machine as a diagnosis step.
There are plenty of articles that address SQL Server connectivity issues - do a Google search for the specific error message that comes up or failing that as a specific question on Server Fault

Faced this problem recently and found the resolution that worked for me.
By the way, setting Timeout = 0 helped to avoid the exception, but the execution time was unreasonable, while manual execution of the store procedure took a few seconds.
Bottom line:
I added SET IMPLICIT_TRANSACTIONS OFF to the stored procedure that is used to fill the data set.
From MSDN:
The SQL Server Native Client OLE DB Provider for SQL Server and the
SQL Server Native Client ODBC driver automatically set
IMPLICIT_TRANSACTIONS to OFF when connecting. SET
IMPLICIT_TRANSACTIONS defaults to OFF for connections with the
SQLClient managed provider, and for SOAP requests received through
HTTP endpoints.
[...]
When SET ANSI_DEFAULTS is ON, SET IMPLICIT_TRANSACTIONS is ON.
So I believe that in my case defaults weren't as required. (I couldn't check that. Don't have enough privileges on SQL server). But adding this line to my SP solved the problem.
IMPORTANT: In my case I didn't need the transaction, so I had no problem to cancel the implicit transaction setting. If in your case transaction is a must you, probably, shouldn't use this solution.