Count equivalent

[o1110010]

i was going to write asking what the Count([tablename]) equivalent was but i believe i found the answer by searching this forum! (the moderators and admins may like to hear that.. ) now this thread is more of a...

thank you for existing!!! i am a new registrant to these forums. i should be able to catch onto vba pretty easy since i have c/c++/java background; then i can contribute back! btw, hi!


just to double-check, the equivalent would be tablename.RecordCount, right?
(.. assuming that's declared already)

 

[raskew]

i was going to write asking what the Count([tablename]) equivalent was but i believe i found the answer by searching this forum! (the moderators and admins may like to hear that.. ) now this thread is more of a...

thank you for existing!!! i am a new registrant to these forums. i should be able to catch onto vba pretty easy since i have c/c++/java background; then i can contribute back! btw, hi!


just to double-check, the equivalent would be tablename.RecordCount, right?
(.. assuming that's declared already)

The way this normally plays out is something like this:

Function Countem(pTblName As String) As Integer

Dim db  As Database
Dim rs  As Recordset
Dim i   As Integer

Set db = CurrentDb
Set rs = db.OpenRecordset(pTblName)
With rs
    .MoveFirst
    .MoveLast
    i = rs.RecordCount
    .MoveFirst
End With

rs.Close
db.Close
Countem = i

End Function

Using the rs.RecordCount business without the

rs.MoveFirst
rs.MoveLast

...may, in some circumstances return an incorrect
result.

HTH - Bob

 

[dcx693]

Unless you have a very large recordset, it's best to do what Bob suggests (though I believe you just need to do a .MoveLast to fill the recordset and make the count accurate, you don't need the .MoveFirst).

If know you're using a table-type recordset, i.e. you are opening a recordset on a local Access table like this: Set rs = db.OpenRecordset(pTblName, dbOpenTable) then you do not need the .MoveLast to fill the recordset to make the count accurate.

By the way, just to make this all even more complicated, all of the above applies to DAO recordsets - not ADO recordsets. I forget the details, but I believe most ADO recordsets fill the recordcount properly without the need for .MoveLast.

 

[o1110010]

DAO good? ADO bad?

sorry for the delay. i read the posts the day they were posted but just haven't been able to get around to work on the database until today.

you brought up DAO and ADO. the closest article i could find on the forum is http://www.access-programmers.co.uk/forums/showthread.php?t=61060 but it leaves me a bit confused. if ADO is the direction of "the future", as microsoft sees it, then why am i seeing so many comments that seem negative about it? or articles pushing individuals to use DAO?

what are some coding differences? any simple examples of the differences? for instance, if a user clicks a form's button to automatically add certain data to pre-defined fields in a table. pretty simple but what would the difference in code be?

thank you!

** i'm also curious to know the percentage of DAO-primary users compared to ADO. is there a existing poll already?