I'm usign mobile for insert rows into a local sqlserver.
Some times the sql server doesnt responde and i'm forced to wait for getting exception.
I have set sqlConnetion time out to 3 seconds
SqlConnection con = new SqlConnection("Data Source = " + MyIp + "; Initial Catalog = database; user id = sa; password = 1234;Connection Timeout=3");
The problem is that sometimes i need to wait 30 seconds.
This time as i can understand is cmd execute timeout.
con.Open();
SqlCommand cmd = new SqlCommand("Insert into customers(Name) values(name123)",con);
cmd.ExecuteNonQuery();
con.Close();
So first question Sql connection time out doesnt include both of them?
Second question if sql doesnt responde then why dont i get first exception in 3 seconds?
And last question why sql server sometimes doesnt responde over network?
Can it be big network(traffic) delay , between mobile and server?
The timeout that you define on the SqlConnection is only applied on the connection. It won't affect any command.
You can change the timeout of the command by doing
cmd.CommandTimeout = 30;
Unfortunately, I can't help you with the last question.
All in one here and someone will probably provide more detailed information but essentially the timeout you are setting is just one of MANY timeout settings that exist at different layers. Some of those layers are on the SQL server side, some are in the .Net framework side and some are user set like yours on the actual connection. Figuring out WHICH timeout setting is taking precedence can be a challenge.
More importantly though is WHY this operation is taking so long. What you provided should be fast enough that none of this should even be an issue. It does not get any simpler than what you are trying to do which should be almost instantaneous. I can assure you it is NOT the SQL server itself, unless you have literally billions of records in that table with every column indexed and even then I doubt its the server spending all this time on the query and has to be something in the transport. There is no way we can troubleshoot that with just the info provided.
Related
I have a windows form application written in C# that passes a query to a SQL Server database and then displays the results in a dataviewgrid. The query that is passed to the database depends on the option selected in the form.
One particular query takes a little over a minute to run in management studio, but timeouts when it is passed to the database from the program. here are the steps I have done to try to resolve the situation:
Added a 5 minute timeout in the program by setting the connection timeout option to 300 seconds in the sql connection string. Example: Data Source=ab;Initial Catalog=abc;User ID=user; Password =pw; Connection Timeout=300
Setting the remote query timeout in the SQL Server instance to 0 (meaning, no timeout). Example: EXEC sp_configure 'remote query timeout', 0 ; GO
Neither of these options work. Despite implementing both of them, the c# program throws back a sql timeout error after less than a minute.
Is there a workaround for this? I have searched for this topic on stack overflow and so far all of the suggestions have been to do either 1 or 2 (which I have done).
For reference, I am using Visual Studio 17 Community edition and SQL Server 2016 Developer edition.
Any help would be greatly appreciated.
Thanks!
There's a "CommandTimeout" property on the SQL command. Try setting that.
Connection timeout and command timeout are two different things.
A connection timeout occurs when a connection cannot be retrieved from the connection pool within the allotted timeout period.
A command timeout occurs when a connection has been retrieved, but the query being executed against it doesn't return results within the allotted command timeout period. The default command timeout period in ADO.NET is 30 seconds.
If you've set the connection timeout to 300 seconds and you're still getting a timeout, it's likely a command timeout. As walkers01 said, set your command timeout to a suitable number of seconds. 300 seconds should be far more than sufficient; if your query executes in one minute in SSMS, a timeout of 90 seconds should suffice.
Try this for unlimited time of query execution if you are using SqlDataAdapter. I have use this one, solved my problem.
SqlDataAdapter dscmd = new SqlDataAdapter(sql, cnn);
dscmd.SelectCommand.CommandTimeout = 0;
We migrated some piece of old software to a new server. We used SQL Server 2008 Enterprise in the past and now we are using SQL Server 2014 Enterprise on a new machine, so it should be faster now.
The old software is legacy software and about to expire, therefore I don't want to put much effort in fixing it. But for some reason there is a C# function running a SQL query against the database for which I get the error message
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
All I read about that is, that I have to extend the timeout time by using CommandTimeout. But unfortunately everything runs under "context connection = true". Therefore, it would take quite a bit work to rebuild this function with an opportunity to change the timeout.
And I'm asking myself, why did this run on the old machine and way it won't on the new one. So it has to do something about the new machine or the new SQL Server engine. Is there any way to change the standard timeout of 30 seconds for a command in the .NET Framework or in the SQL Server?
Thanks a lot for any suggestions!
You can set the timeout of a command with the CommandTimeout property:
var cmd = new SqlCommand { CommandTimeout = 60 }
Ok, I didn't find a sollution for the problem, yet, but the timeout is not really the source of the problem. I gained access to the old system and run some tests and it turned out that the same function on the old machine with the old server software runs a lot faster, such that there is no timeout.
Hence, I have to focus on server speed and database tuning.
Thanks to everyone who occupied himself with this question!
Edit:
I found a solution to my problem, indirectly. I couldn't find out, why the execution of the statement on the new machine takes so long. But it turned out that the statement itselft uses table variables. I changed them to a local temporary table in the database tempdb. Now the execution takes less than one second instead of more than 7 minutes!
For me, it looks like a problem with some cache or a miss-configured SQL server. Unfortunately, I'm not really the server administrator and I will not twiddle with it. But I will mention it to the administrators. At least, the program runs now perfectly.
I have more than 12k records.
Default configured is 30 sec for connection time out. In this scenario i am getting exception like sql connection time out is closed.
I configured connection time out 0 for executing from c#.
Any disadvantage for set to value is 0.
Please suggest which value is fine for connection timeout. Please keep in mind I have huge data like 12k to 50k.
A value of 0 indicates no limit, and should be avoided in a ConnectionString because an attempt to connect waits indefinitely.
Making connection depends on database,drivers, it is local or remote.
You can not pin point some specific value knowing all these things. value doesn't depends on number of records.
if some problem occur while processing some specific record and it takes too long and you don't want to wait for so long in order to save time. Set CommandTimeout property but it has nothing to do with connection state
How can I limit timeout for connecting to Oracle Database? I use devart dotConnect Express Edition on data access layer. I tried add Connection timeout=30; to connection string but it doesn't give right result (even a little weird, first time it really limits to 30 seconds, but not on all connection attempts). Then I find out that
Connection Timeout Time (in seconds) to wait while trying to establish
a connection before terminating the attempt and generating an error. A
value of 0 indicates no limit. The default value is 15 seconds.
Available in Direct mode only.
from Devart site
I can't use direct mode because I use Express Edition. Then I tried to set this parameters in TNSNAMES.ORA
DB1 =
(DESCRIPTION =
(CONNECT_TIMEOUT=11)
(TRANSPORT_CONNECT_TIMEOUT=10)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.100.8)(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = DB1)
)
)
Still works incorrect. OK, going down and try yo set connection timeout in SQLNET.ORA
SQLNET.INBOUND_CONNECT_TIMEOUT = 5
Another one fail! Does anyone know how can I set timeout restricting allowing time to connect to DB1? It now finishes connection (connection fails) for approximately 20 seconds.
I've never used Devart's dotConnect library, but looking at the OracleConnection class it seems that you should be able to close the connection after a certain period of time by calling OracleConnection.Close(). This should take you out of the blocking state while you're trying to Open the connection.
This is not exactly like setting the timeout, but it may work. Furthermore, check the ConnectionTimeout property when you're debugging this code in order to confirm that the timeout is properly set.
OracleConnection.ConnectionTimeout works in Direct mode only. It is ignored when connection is established via Oracle client, which manages connection in this case.
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.