We have a customer who is experiencing Time-outs in our .NET application which uses SQL Server as the backend.

The table in question is the OrderLines table in a SQL Server Database that has 4155151 rows

Lately, the customer has reported, that intermittently they would get these Time-Outs during the process of updating this table.

The code doesn't have a specific Time-out set in the Connection String to the Database but on the SQL Server, the Time-out is set to 10 minutes.

The error reported is as follows:

Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

at System.Data.Common.DbDataAdapter.UpdatedRowStatusErrors(RowUpdatedEventArgs rowUpdatedEvent, BatchCommandInfo[] batchCommands, Int32 commandCount)
at System.Data.Common.DbDataAdapter.UpdatedRowStatus(RowUpdatedEventArgs rowUpdatedEvent, BatchCommandInfo[] batchCommands, Int32 commandCount)
at System.Data.Common.DbDataAdapter.Update(DataRow[] dataRows, DataTableMapping tableMapping) at System.Data.Common.DbDataAdapter.UpdateFromDataTable(DataTable dataTable, DataTableMapping tableMapping) at System.Data.Common.DbDataAdapter.Update(DataTable dataTable)

We have checked the Indexes for this table and it seems ok (see image attached).

The customers IT guys have checked processes/tasks running on the server throughout the day, and did mention they recently updated to .NET 4.6.1 . Also, they mentioned they have plenty of RAM allocated and disk latency is fine and CPU is fine as well.

Any ideas on how to trouble shoot this issue further?

Stats for Customer Order Line Table Indexes

  • I'd suggets to check for blockings during the execution time, also how does your execution plan looks? Even the indexes are ok, if the query is not using it you may have bad performance.
    – dbamex
    Commented Jun 17, 2019 at 4:19
  • Agree. Check for blocking or try to identify the query when it is slow and do query performance work on it. Also, for the record, there's no server setting for a client time-out (it is always indefinite). The one mentioned is probably for SQL Server to SQL Server queries (linked servers), commonly mistaken for a server-wide client timeout setting. Commented Jun 17, 2019 at 6:26
  • May I know did you get your issue fixed? Our application team faces the same issues (just that theirs is trying to delete). On SSMS, the query took only a few seconds, and the execution plan looks normal, nor there is any blocking etc. Similarly, it happens intermittently and there isn't any patterns to trace it.
    – Yoshiaki
    Commented Sep 23, 2020 at 3:45
  • @Yoshiaki with this issue I believe we did up finding what was happening. From memory I believe there were a couple of SQL Queries that were slowing down the entire system, so after we had identified these, we re-created the SQL Queries to optimise it. Commented Sep 29, 2020 at 3:52

1 Answer 1


The code doesn't have a specific Time-out set in the Connection String to the Database but on the SQL Server, the Time-out is set to 10 minutes.

You are most probably reaching a client timeout which by default is 30 seconds for C# SQL Server client (ADO.NET?). Consider increasing this timeout until you find a decent solution that does not force the client into waiting so much time.

We have checked the Indexes for this table and it seems ok (see image attached).

Typically indexes are not OK by default, but based on actual SELECT queries that hit the table. In your case you seem to issue an UPDATE and the first thing that comes into my mind is that you have a lot of indexes (5) on that table and UPDATE might need to also update most of them. Just from the name, idx_ordernumber and idx_ordernumber_Status seem to be very similar and they might be merged into a single index.

The following is mostly an approach made by a .NET programmer and it is not optimal from a DBA's perspective, but it might provide useful insight before diving into more DBA savvy stuff. Try this on a development / test database that has little activity, but a data volume similar to that from production:

  1. Run SQL Server Profiler (yes, it is deprecated, but the tool is still very useful for quick checks)

  2. Create a new trace and double check that you are filtering by your database, remove audit events and include events like *:Starting + *:Completed

  3. Run your UPDATE scenario. You should see some queries and I expect that your problematic query to be more expensive (perhaps a rather large duration). Also, this step might reveal another issue: lots of queries issued by that "update" bundled into a single transaction that might take a very long time (in spite of each being very quick). This later is a client side issue, not a DB one.

  4. You might run the query again in SQL Server Management Studio by also including Actual Execution Plan to see what is causing the rather long execution

If you still do not figure out what is the cause, edit your question and provide what you have found out: the query, the execution plan, duration etc.

  • Alexei thanks mate, will look into what you mentioned. Commented Jun 17, 2019 at 11:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.