rdoResultsets

rdoResultsets are rows of data contained in columns. They are like DAO recordsets, but with some significant differences. rdoResultsets can contain more than one set of records with different columns in each set. There are no FindFirst, FindNext, or FindPrevious methods. Updates to the resultset can be batched together and sent back to the server in one operation. rdoResultsets can be opened asynchronously, which allows the client application to get on with something else while the server is busy. And there are several events that fire when data is ready or when a resultset is associated with (or dissociated from) an rdoConnection.

You can open an rdoResultset from either an rdoConnection or an rdoQuery. If you use an rdoConnection as the basis for the resultset, you then, of course, have to supply an SQL command. An rdoQuery, on the other hand, contains the SQL command that is to be executed, as you see here:

Set rsLogins = conPiConnection.OpenResultset(strSQL, _
    rdOpenForwardOnly, rdConcurReadOnly, rdExecDirect)
Set rsUsers = qryUsers.OpenResultset(rdOpenKeyset, _ 
    rdConcurLock, rdAsyncEnable)

The parameters on the OpenResultset method are the SQL command (for opening from a connection), the type of cursor, the type of locking (also known as concurrency—hence, the values all start with rdConcur), and the options for asynchronous or direct execution. Not all of the possible parameter combinations make sense or are supported. For example, it doesn’t make sense to use rdOpenKeyset with rdConcurReadOnly. One of the points about a KeySet cursor is that it is updatable. If you wanted a read-only, scrollable cursor, you would use rdOpenStatic instead of rdOpenKeyset. Some options might not be available because of the limitations of the back-end database or the ODBC driver. The cursor type and locking parameters must be chosen very carefully for every query and resultset you create.