Qualify DAO referance

[Albert D. Kallal]

I have the following code that assumes a form ref, and also assumes DAO.


For Each OneField In frmF.RecordsetClone.Fields


The problem is that in some cases, even when a DAO reference is set, the
above does not work. (the DAO ref has to be higher in the refs).

Is there anyway to qualify the above DAO recordset so I can eliminate the
need to have DAO higher then ADO?

 

[Andrew Smith]

I did a few tests with the ADO reference above the DAO reference.

This did not work:
Dim fld As Field
For Each fld In Me.RecordsetClone.Fields
Debug.Print fld.Name
Next

This did work:
Dim fld As DAO.Field
For Each fld In Me.RecordsetClone.Fields
Debug.Print fld.Name
Next

This also worked:
Dim fld As DAO.Field
Dim rst As DAO.Recordset
Set rst = Me.RecordsetClone
For Each fld In rst.Fields
Debug.Print fld.Name
Next

But the same thing failed without the DAO. in front of Field.

With the DAO reference higher than ADO, all the above worked.

So, as far as I can see it's not necessary, in the case of form recordset
clones, to qualify the recordset as DAO, but it is necessary to qualify the
field object as DAO.

 

[Brendan Reynolds \(MVP\)]

The syntax "For Each fld In Me.RecordsetClone.Fields" doesn't require you to
disambiguate any recordset variable, because it doesn't *use* any recordset
variable - you're not assigning the RecordsetClone to a variable. If,
instead, with the ADO reference first, you'd assigned the RecordsetClone to
a variable ...

Dim rst As Recordset
rst = Me.RecordsetClone
For Each fld In rst.Fields
'etc.

.... then you would have encountered an error, as the variable rst would have
been an ADODB recordset by default.

In other words, the reason you needed to disambiguate fld but didn't need to
disambiguate a recordset variable is not because of a difference in the
behaviour of Field and Recordset objects, but because you were assigning to
a Field variable, but were working directly with the RecordsetClone object
without assigning it to a variable.

Michael Kaplan's article at the following URL may be of interest in this
context: http://www.trigeminal.com/usenet/usenet022.asp