StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POResolving an ADO timeout issue in VB6
text
Body
copied!<p>I am running into an issue when populating an ADO recordset in VB6. The query (hitting SQLServer 2008) only takes about 1 second to run when I run it using SSMS. It works fine when the result set is small, but when it gets to be a few hundred records it takes a long time. 800+ records requires about 5 minutes to return (query still only takes 1 second in SSMS), and 6000+ takes well over 20 minutes. I have "fixed" the exception by increasing the command timeout, but I was wondering if there was a way to get it to work faster since it does not seem to be the actual query that requires so much time. Something such as compressing the results so it doesn't take as long. The recordset is opened as follows:</p> <pre><code>myConnection.CommandTimeout = 2000 myConnection.ConnectionString = "Provider=SQLOLEDB;" & _ "Initial Catalog=DB_NAME;" & _ "Data Source=SERVER_NAME" & _ "Network Library=DBMSSOCN;" & _ "User ID=USER_NAME;" & _ "Password=PASSWORD;" & _ "Use Encryption for Data=True;" myConnection.Open myRecordSet.Open STORED_PROC_QUERY_STRING, myConnection, adOpenStatic, adLockReadOnly Set myRecordSet.ActiveConnection = Nothing myConnection.Close </code></pre> <p>The data returns 3 columns used to fill a combo box.</p> <p>UPDATE: I ran SQL Profiler, and the instances from the client machine make more reads and takes more time by a factor of 100 than both metrics for the queries in SSMS. The text of the query is the same for both SSMS and the client machine according to the profiler, so I don't think it should be using a different execution plan. Could the network library or the Provider have any impact on this?</p> <p>Profiler stats:</p> <ul> <li>From the client application: 7041720 reads, 59458 ms duration, 3900 row counts </li> <li>From SSMS: 30802 reads, 238 ms duration, 3900 row counts</li> </ul> <p>It seems like it is using a different execution plan, but the query is exactly the same and I am not sure how to check the execution plan the client might be using if it is different from what is shown in SSMS.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload