rst.CursorLocation = adUseClient (1 Viewer)

[garethl]

what i am wondering is what the line of code in the title actually means!

i have read some posts from the archives of this forum about getting a recordcount of a recordset which said that if you don't put this line in then your recordcount will return zero

i have tried my code both with and without this line and sure enough it works fine when you put in

rst.CursorLocation = adUseClient

before opening the recordset and sure enough the count returns zero if you don't put in that magic line of code, its just that none of the posts i read tell me WHY this makes such a difference or what it actually means

intellisense tells me that the alternative to

rst.CursorLocation = adUseClient

is

rst.CursorLocation = adUseServer

so i am guessing that its the difference between the database being held on the local machine and it being (split?) with the backend on a server and front end on the local machine

does this mean that if i was to split my database so the tables ect. were stored on a central server then i would observe the opposite behaviour of recordcount returning zero without

rst.CursorLocation = adUseServer

i would like to find out because this is what is intended to do with the database in the near future - and just because i like to know what my code means

 

[RoyVidar]

Usually, when ADO cannot determine the recordcount, it returns -1, not 0.

Client side cursor comes at a cost.

Check out for instance http://www.adopenstatic.com/experiments/clientsidecursortypes.asp, http://msdn2.microsoft.com/en-us/library/ms676564.aspx and http://www.slxdeveloper.com/page.aspx?action=viewarticle&articleid=33.

Are you sure you need the recordcount? I very seldom need the recordcount, I only need to find out whether there are records in the recordset or not, which I check through it's .bof/.eof properties. Anyway, there may be reasons other than cursor/locktype making ADO unable to determine the recordcount (i e, basically, in my opinion, the ADO .RecordCount is not reliable), so if you really need the recordcount, you should do a SELECT COUNT(*) FROM ... with the same where clause...

Anyway, most use DAO when working with Jet tables.

 

[garethl]

yeah sorry it returns -1 i was testing whether or not it was greater than zero

and it sounds like i don't need it i - i just need to check whether or not there are records in the recordset, so how do you do it? test whether bof = eof

they are import errors, user batch imports a load of data in an excel file and i run a query to see if there is anything that doesn't match up to my lookup tables, if there is unrecognised stuff in there the database starts giving the user error messages and displays the records containing bad data for them to sort it out

anyway cheers for the articles i'll read them over my breakfast and find out why not to use the recordcount!

 

[garethl]

makes sense now thanks and yeah it doesn't sound like its the best thing to do just to get a count

i'll be having a look at switching the recodset parts of this beast back to DAO as well - so why is DAO so much better?

 

[RoyVidar]

I'm the wrong person to ask, as I'm one of the very few who do use ADO also for Jet tables, except when I manipulate a "native" form recordset (which is DAO, unless you work wiht ADPs or set it explicitly).

But here's one reason - since most developers use DAO for Jet tables, you're more likely to get answers to questions, and will easier search out solutions to common problems etc