Recordsetclone error

  • Thread starter Thread starter dennis
  • Start date Start date
D

dennis

I have a form called test based on a table called
clli_code. I have attached the following to the On_click
event:

dim rst as recordset
set rst = me.recordsetclone


I keep getting a 'runtime error 13, type mismatch'

What am I doing wrong?

Thanks in advance
 
I keep getting a 'runtime error 13, type mismatch'
Click to expand...

In the VBEditor, check Tools -> References and check the setting for
Microsoft Data Access Objects 3.6. Either move it above the ADO entry, or
uncheck ADO if you don't plan to use it.

DAO used to be default for Access 97, but it was changed to ADO for Access
2000 and upwards (although nobody told the Jet team...)

HTH


Tim F
 
Thanks, Tim!!

I wish I had known this 8 hours ago!

Problem is now that my form doesn't see a keypress event
on my subform.
 
Dennis,

I have run into this also. The odd thing is with the new
version of Access using primarily ADO based programming,
the recordsetclone propertyis still DAO based. Not sure
why MS did this, but I imagine it was based around
backward compatibility issues.

Dim rst as Recordset

dimensions the variable rst as an ADO recordset. Setting
rst to Me!recordsetclone tries to set and ADO recordset
variable to a DAO recordset object - and that's the
reason for the type mismatch error.

Interestingly, this only occurs in database files - those
saved with the *.mdb file extention. If your project were
save as an Access project file (*.adp) then the
recordsetclone property returns and ADO recordset object.

One approach to work around this - if all your other
programming has been under ADO, is to use the
recordset.clone function. This creates a new recordset
object that is a clone of the original.

Recordsetclone creates a second record pointer in the
same recordset, Recordset.clone creates a completely new
recordset. The bookmarks are the same between the two.
One difference is that the clone opens with the first
record as the current record - regardless of which record
is current in the original. Since they are seperate
objects, you can close either one without affecting the
other. They will stay in synch until you exicute a
Requery method on the original.

This is a valid work around under ADO, but is does take a
little more management in your code.

Hope this give you a little better insight.

-dc
 
Back
Top