ADODB RecordCount, or OUTPUT parameter in stored procs: best practice

keywords: ADODB CursorType CursorLocation RecordCount Output Parameter Stored Procedure  best practice
==========================================================

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?

Thanks!

Dennis
dtleahyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

NightmanCTOCommented:
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.
0
QPRCommented:
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.
0
dtleahyAuthor Commented:
Nightman and QPR, thanks for the rapid replies!

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.

Dennis
0
NightmanCTOCommented:
You should just be able to use rs.RecordCount instead of having the overhead of performing a seperate count statement inside the stored procedure.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
dtleahyAuthor Commented:
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.

Thank you both!

Dennis
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.