Home/ Questions/Q 7404749
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T05:18:00+00:00

I am running into timeout issues with a very straightforward query. It seems to

  • 0

I am running into timeout issues with a very straightforward query. It seems to be because it can potentially return a very large number of results.

It’s working against a table that stores an edge list for a weighted graph:

CREATE TABLE Graph
    (Node1 int not null,
     Node2 int not null,
     Weight real not null,
     UNIQUE NONCLUSTERED (Node1, Node2))

The query is simply searching for a particular Node1:

SELECT Node1, Node2, Weight from Graph where Node1 = @node1

The query plan is okayish – a nonclustered index seek and a RID lookup. Naturally I’m going to have to see if I can get that unique nonclustered index switched over to a primary key. This table’s huge (about 60 gigs, data and index) so I’m sure the disk is getting one heck of a workout.

I’m worried that won’t entirely solve my problem, though. The timeout happens after I’ve had quite a lot of time to spin through my SqlDataReader, and I’m not having any responsiveness issues with the reader itself – the server’s being perfectly communicative. I suspect the real problem is related to this note from the documentation for SqlCommand.CommandTimeout:

This property is the cumulative time-out for all network reads during command execution or processing of the results. A time-out can still occur after the first row is returned, and does not include user processing time, only network read time.

It seems I’m getting the timeout on queries that return particularly large result sets, simply because it takes a while to transfer them over the network. Is there a better way to be doing this? It seems there should be some way to say, “I only want a timeout in the event of an actual failure to communicate.”

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    when a real failure happens you usually get an exception…

    IF you are really sure that you want to deal with this client-side (instead of optimizing the server-side for example by giving the server 128 GB of RAM) then you could 

    SqlCommand.CommandTimeout = 0; // or an extremely high value

    According to MSDN this represents “no timeout”.

    alternatively you can run this command on a connection opened with context connection=true in its connection string…

    • 0