[AccessD] ado recordcount

In fact I was just trying to get a record count for testing purposes.  I was
opening a recordset (I thought) and then passing that recordset to another
class, where a "find" was not working.  No se por que.  I ended up replacing
the table name with a SQL string and it started working.  Problem solved, no
recordcount required for testing.

The odd part is that I was opening a different recordset and doing a search
(find) inside of the class, but when passed to another class many of the
recordset properties started failing.  I'd get errors like "addition of this
record failed due to ..." when all I was doing was a find operation.  I
hadn't even done an addrec.  Weird stuff.  However by using a SQL String
instead of the table name, this problem went away.  Again, weird stuff.  I
must admit I'm not an ADO head though so who knows what I was really doing.

In this application, In my form class I am looking for a record in a table
for the form (thus the .Find) and if none found, create a new record.  I
tried the identical thing for controls, but in order to speed things up I
open the recordset in the form class and pass it off to the control class
being instantiated, where the .Find is failing.  I could open the table
directly (Identical code, stolen to do the control recordset), but had to
use an SQL statement for the control recordset.

With much wasted time figuring that out.

Sigh.

John W. Colby
www.colbyconsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Lawrence
(AccessD)
Sent: Sunday, October 19, 2003 11:06 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] ado recordcount


Hi John:

In addition to the information supplied by Dave Sharpe with using a server
side cursor location will cause issues. Use 'rs.CursorLocation =
adUseClient' instead of 'rs.CursorLocation = adUseServer'. Most work can be
done with 'static' cursor types. Use adOpenKeyset type cursors only when
updating or deleting and use a pessimistic lock so as to not over-write a
record being used by another.

My two cents worth
Jim