I need to get record counts on some recordsets that will be retrieved via ADODB command objects, using stored procedures. I'd like to know the wisest way to do this.

For a small (low traffic, few users) desktop client-server app using SQL Server 2005 through ODBC connection, in a small office LAN with a handful of workstations, is it faster/better to retrieve the ADO RecordCount by

A.) using an OUTPUT parameter in the stored proc that holds the COUNT
or
B.) use an appropriate CursorType, CursorLocation, and read the .RecordCount property from the recordset? (adOpenStatic and adUseServer?)

I'm sure there are times when both methods are wisest ("best practice"), but if I do not need to traverse the recordset more than once (forward), is there a performance penalty or something else that dictates which method to use?

As a general principle, output parameter will be faster. In fact, you don't even have to create a recordset, simply execute the command and interrogate the output parameter. remember, you will not be returning the results set (less network traffic, CPU, memory across the board) simply the single parameter.

If worried about performance you could ditch the recordset once retrieved and put the rows into an array using GetRows. Then you have the count and the ability to traverse back/forward as many times as you like.

I do need the recordsets, I should have stated that. The recordcount is just to be used for programming logic:

If rs.RecordCount > 1 Then
bla bla bla
End If

kind of thing.

You know, I never bothered to use GetRows until doing an ecommerce website with SQL Server on the backend. It is an excellent strategy, especially for web applications. This current (desktop) project was originally written using Access, and I'm porting it over to use a SQL Server backend. Quite honestly, I don't really have the time right now to change all the code necessary to access recordset records/fields as array items (which I also think are all typecast as variants, if I remember correctly), but that may be good to keep in mind for an update to the code sometime later. For now, I just want to replace Access/Jet with SQL Server, add some stored procs, and use the existing code logic for recordsets.

I'm awarding most of the points to Nightman, because I believe it's the correct answer. But, for those coming after me and searching for answers to performance problems and that need a count of records, especially in web applications, the GetRows strategy is wise, so QPR gets some points and is marked as an assist.

Introduction
SQL Server Integration Services can read XML files, that’s known by every BI developer. (If you didn’t, don’t worry, I’m aiming this article at newcomers as well.)
But how far can you go? When does the XML Source component become …

This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code.
This l…