To open a recordset, we use the .Open
method of the recordset object and pass in the name of the table we want to be placed in the recordset (as well as the name of the open connection) as parameters. In this example, we can open a recordset with only two parameters as shown:
adoRecordset.Open "Publishers", adoConnection
Once the recordset is opened, we simply loop through like we did using DAO. In fact, the syntax to access a field is exactly the same using the recordset!field notation. So once we open the recordset, the programming is almost identical to DAO:
Do Until adoRecordset.EOF
List1.AddItem adoRecordset!Name
adoRecordset.MoveNext
Loop
Finally, when we want to close both the recordset and connection, just use the Close method of both objects:
adoRecordset.Close
adoConnection.Close
set sdoRecordset = Nothing
set adoConnection = Nothing
We certainly did dimension these object variables locally - they only exist in the click event procedure of the command button. As such, they go out of scope when the program leaves the procedure. So if we omitted the .Close
methods, both would be closed by default when they go out of scope. But we have been talking consistently about not relying on the default behavior of Visual Basic. This has to do with both initializing variables as well as releasing them. So it is good form to explicitly close both of the object variables before exiting the procedure. We should also set both object variables to Nothing
which effectively releases the pointers to them and frees up the memory they consume.