How to read data using SQLGetData from a block, forward-only cursor (ODBC)

Question

Hi there.  I am trying to read data a small number of rows of data from either a Microsoft Access or Microsoft SQL Server (whichever is being used) as quickly as possible.  I have connected to the database using the ODBC API's and have run a select
statement using a forward-only, read-only cursor.  I can use either SQLFetch or SQLExtendedFetch (with a rowset size of 1) to retrieve each successive row and then use SQLGetData to retrieve the data from each column into my local variables.  This
all works fine.
My goal is to see if I can improve performance incrementally by using SQLExtendedFetch with a rowset size greater than 1 (block cursor).  However, I cannot figure out how to move to the first of the rowset returned so that I can call SQLGetData to retrieve
each column.  If I were using a cursor type that was not forward-only, I would use SQLSetPos to do this.  However, using those other cursor types are slower and the whole point of the exercise is to see how fast I can read this data.  I can
successfully read the data using a block forward only cursor if I bind each column to an array in advance of the call to SQLExtendedFetch.  However, that has several drawbacks and is documented to be slower for small numbers of rows.  I really
want to see what kind of speed I can achieve using a block, forward-only, read-only cursor using SQLGetData to get each column.
Here is the test stub that I created:
' Create a SELECT statement to retrieve the entire collection.
selectString = "SELECT [Year] FROM REAssessmentRolls"
' Create a result set using the existing read/write connection. The read/write connection is used rather than
' the read-only connection because it will reflect the most recent changes made to the database by this running
' instance of the application without having to call RefreshReadCache.
If (clsODBCDatabase.HandleDbcError(SQLAllocStmt(gDatabase.ReadWriteDbc, selectStmt), gDatabase.ReadWriteDbc, errorBoxTitle) <> enumODBCSQLAPIResult.SQL_SUCCESS) Then
GoTo LoadExit
End If
Call clsODBCDatabase.HandleStmtError(SQLSetStmtOption(selectStmt, SQL_CONCURRENCY, SQL_CONCUR_READ_ONLY), selectStmt, errorBoxTitle)
Call clsODBCDatabase.HandleStmtError(SQLSetStmtOption(selectStmt, SQL_CURSOR_TYPE, SQL_CURSOR_FORWARD_ONLY), selectStmt, errorBoxTitle)
Call clsODBCDatabase.HandleStmtError(SQLSetStmtOption(selectStmt, SQL_ROWSET_SIZE, MAX_ROWSET_SIZE), selectStmt, errorBoxTitle)
If (clsODBCDatabase.HandleStmtError(SQLExecDirect(selectStmt, selectString, Len(selectString)), selectStmt, errorBoxTitle) <> enumODBCSQLAPIResult.SQL_SUCCESS) Then
GoTo LoadExit
End If
' Cursor through result set. Each time we fetch data we get a SET of rows.
sqlResult = clsODBCDatabase.HandleStmtError(SQLExtendedFetch(selectStmt, SQL_FETCH_NEXT, 0, rowsFetched, rowStatus(0)), selectStmt, errorBoxTitle)
Do While (sqlResult = enumODBCSQLAPIResult.SQL_SUCCESS)
' Read all rows in the row set
For row = 1 To rowsFetched
If rowStatus(row - 1) = SQL_ROW_SUCCESS Then
sqlResult = clsODBCDatabase.HandleStmtError(SQLSetPos(selectStmt, row, SQL_POSITION, SQL_LOCK_NO_CHANGE), selectStmt, errorBoxTitle)
Call clsODBCDatabase.SQLGetShortField(selectStmt, 1, assessmentRollYear(row - 1))
Console.WriteLine(assessmentRollYear(row - 1).ToString)
End If
Next
' If the rowset we just retrieved contains the maximum number of rows allowed, there could be more data.
If rowsFetched = MAX_ROWSET_SIZE Then ' there could be more data
sqlResult = clsODBCDatabase.HandleStmtError(SQLExtendedFetch(selectStmt, SQL_FETCH_NEXT, 0, rowsFetched, rowStatus(0)), selectStmt, errorBoxTitle)
Else
Exit Do ' no more rowsets
End If
Loop ' Do While (sqlResult = enumODBCSQLAPIResult.SQL_SUCCESS)
The test fails on the call to SQLSetPos.  The error message I get is "Invalid cursor position; no keyset defined".  I have tried passing SET_POSITION and also SET_REFRESH.  Same error.  There has to be a way to do this!
Thank you for your help!
Thank You! - Andy

Answer 1

Hi Apelkey,
Thank you for your question. 
I am trying to involve someone more familiar with this topic for a further look at this issue. Sometime delay might be expected from the job transferring. Your patience is greatly appreciated. 
Thank you for your understanding and support.
Regards,
Charlie Liao
TechNet Community Support