title: Resolving an ADO timeout issue in VB6
body: <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;" &amp; _
          "Initial Catalog=DB_NAME;" &amp; _
          "Data Source=SERVER_NAME" &amp; _
          "Network Library=DBMSSOCN;" &amp; _
          "User ID=USER_NAME;" &amp; _
          "Password=PASSWORD;" &amp; _
          "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>