Type mismatch

[Alex]

I'm using Access 2002. The following code gives me a type mismatch:

Private Sub Command13_Click()

Dim Rs As Recordset

Set Rs = Me.Recordset

End Sub

If I change my Dim statement to:

Dim Rs As ADODB.Recordset

I still get a type mismatch.

If I try the following:

Dim Rs As DAO.Recordset

then I get the error: Compile error. User-defined type not defined.

I have a reference to Microsoft ActiveX Data Objects 2.5 Library. The
Microsoft DAO Object Libraries are not referenced (they are not checked in the
References dialog). Can somebody please explain to me what's going on?
Ultimately what I'm trying to do is get access to the form's recordset. I'm
working on a company wide application and I already checked that the
workstations are using ADO, not DAO in the Access database applications that
they currently have. I want them to keep using what they are using and not
have to require them to make any changes.

 

[Guest]

You want to use me.recordsetclone and not me.recordset

 

[Alex]

You want to use me.recordsetclone and not me.recordset

I changed the code so that now it looks like:

Dim Rs As ADODB.Recordset

Set Rs = Me.RecordsetClone

Unfotunately I still get a Type mismatch error.

 

[Brendan Reynolds]

Me.RecordsetClone is returning a DAO recordset, not an ADODB recordset. Make
sure you have a reference to the DAO object library and change your
declaration from Rs As ADODB.Recordset to Rs as DAO.Recordset.

 

[Alex]

Me.RecordsetClone is returning a DAO recordset, not an ADODB recordset. Make
sure you have a reference to the DAO object library and change your
declaration from Rs As ADODB.Recordset to Rs as DAO.Recordset.

I'm very confused by this. How is it possible for Me.RecordsetClone to return
a DAO recordset if I don't have a DAO reference? Is there a way to work in
Acccess without DAO? As I mentioned previously I'd much rather not require any
changes to the user's workstations. Ultimately all I'm trying to achieve (at
least at this point) is to get access to the form's recordset so that I can use
Find (or an equivalent) to change the form's current record. Are there any
other alternatives other than using RecordsetClone?

 

[Brendan Reynolds]

Yes, you can work in Access without DAO, if you develop an ADP solution
instead of an MDB. If you're making modifications to an existing application
rather than starting a new one, however, that would be a drastic step, and I
certainly don't recommend it, and especially not if your reason for doing so
was to avoid using DAO, as there isn't any reason to avoid using DAO.

In an MDB, Access uses DAO behind the scenes for many operations, so no,
when using an MDB it is not possible to not use DAO, even when you don't use
DAO, if you see what I mean!

No changes to the users workstations should be required to use DAO - a PC
without DAO 3.6 installed is a very rare animal these days - in fact, you're
much more likely to encounter version problems with ADO than with DAO, as
there are a lot more versions of ADO out there.

You may find the following article of interest, even though it was written
some time ago and some things have changed since then. It is now possible,
in recent versions of Access, to assign an ADO recordset to a form's
Recordset property without making the form read-only. I don't recommend that
either, but it can be done.

http://www.trigeminal.com/usenet/usenet022.asp?1033

 

[Alex]

Brendan. Thank you for the detailed explanation.