> Below is my code as it is today. What is wrong with it and what would
None. They are mutually exclusive.
The fastest recordset on the block is the Server-sided, Forward-only,
read-only cursor with some unspecified cached records. It is is the fastest
_BECAUSE_ it has limited functionality and that includes the fact that it
does not know how many rows it is delivering. So RecordCount is -1 for this
You might try server-sided cursors setting Recordset CacheSize property. I
usually use powers of 2 like 64, 128, ..., 4096. I expect the ideal size
would be NetworkPacketSize / RecordSize. CacheSize is for server-sided
cursors, it is useless for client-sided cursors
As Bob says. If you need the RecordCount, is much much faster to get the
database to calculate it for you in SQL and return a 1 record result.
And for faster performance it would not hurt to look at your WHERE clause
and see if you cannot cut the amount of rows to be joined further down. Less
rows to consider is usually faster. Looking at whether you have the right
indexes also helps (also the most useful index, usually the PK benefits if
it is clustered).
No, very likely not (but try it and see). All it means is that the
Recordset.Open will take longer, because ADO will spend all its time
creating the Recordset in client-sided memory. You might even find that
Windows starts virtual memory swapping as ADO will need a lot of
client-sided memory to contain the entire Recordset. Once Open() returns,
MoveFirst, MoveLast should be fast (that is if it fits in memory and not on
disk) and RecordCount will be valid.
But you will have paid an enormous price to get here. Garguatuan Recordsets
are usually better off being server-sided.