Upgrading your Access Application for a Multi-user Environment - Recordset Object
(Page 3 of 5 )
Recordset Object
If you want the user to navigate through your data, using a recordset object is the commonest way of doing this. A recordset doesn’t need to be opened against a connection object as such. It can be opened by passing in a string parameter that describes a connection. However, it is better programming practice to use a connection object because the programmer has an explicit reference to the object and can set it to “nothing” if need be. For this reason we recommend opening recordsets against existing, explicitly created connection objects.
Find below code to open a recordset against the connection object created above:
Set rsBooks = New ADODB.Recordset
With rsBooks
.ActiveConnection = cnDemo
.Source = "Select * From tblItems"
.CursorType = adOpenDynamic
.LockType = adLockOptimistic
.CursorLocation = adUseServer
.Open
End With
In order to see changes made by other users, we must use a dynamic, server-side cursor. As an aside, CacheSize also has an effect on visibility of changes but only if its default value of “one” is changed.
The default lock type is read-only so we must explicitly use some kind of record locking if we wish to update or change records. We have a choice of using optimistic or pessimistic locking. The difference between these two types, as described by Microsoft, is that a pessimistic lock, “Prevents other users from accessing data while locked”.
Please note that the CursorType is dependent on the CursorLocation. If the cursor location is set to the client then the cursor is static regardless of how it is defined in the CursorType.
Next: Security >>
More Microsoft Access Articles
More By Peter Lavin
/ 34 
