As you have seen in the course of this chapter, you must make several decisions
about cursors when you want to access data with VB and ADO.
These decisions fall into the following categories:
-
Do you really need a cursor at all?
-
Should you build the cursor on the client or on the server?
-
How should the cursor behave?
-
What locking strategy should the cursor implement?
The criterion to use for choosing the right cursor for the job can be stated
in one simple, general rule: Build the cursor that uses the fewest resources and
still does the job. Remember, the most economical cursor of all is the "firehose"
cursor, discussed in the sections titled "Forward-Only Cursors"
and "Using Locking Strategies to Ensure Data
Integrity."
Because of the great array of DBMSs that can be implemented with cursor-implemented
rowsets, you may find that some cursor types will give you more or less functionality than
documented for a particular combination of cursor location, cursor type, or locking strategy.
To find out what the ADO "official line" is on any given Recordset's
capabilities (that is, what ADO believes that the Recordset can do, based on what the provider
believes that it can do), you can use the Recordset's Supports method, passing it one of the following
nine constants (whose names are self-explanatory):
- adAddNew
- adApproxPosition
- adBookmark
- adDelete
- adHoldRecords
- adMovePrevious
- adResync
- adUpdate
- adUpdateBatch
Each of these listed constants refers to some capability of the Recordset.
When one of the constants is passed to the Supports method, the Supports method returns a True or
False value, indicating whether the Recordset has that capability.
The following line of code would set the variable blnCanUpdate to True or False,
for example, and thus tell you whether the Update method would work for the Recordset named rsEmployees:
blnCanUpdate = rsEmployees.Supports(adUpdate)
