DAO reference / Access 2007

while using an Access 2007 .accdb file I can access the dao. object very
easily.
the following code in VBA works well :
Function getrecordcount(strTableName As String) As Long
Dim dbCurrent As DAO.Database
Set db = CurrentDb
Dim rstRecords As DAO.Recordset
Dim rstRecords2 As DAO.Recordset2
Set rstRecords = db.OpenRecordset(strTableName, dbOpenForwardOnly)

all the DAO.xxx references are recognized and are generated from the
Microsoft Office 12.0 Access database engine Object Library, acedao.dll
as evidenced by the ability to reference Recordset2.

but when similar code is generated in Visual Basic 2005 I am unable to
access the dao. object library using the same dao. naming conventions. for
some reason it forces me to use Microsoft.Office.Interop.Access.Dao.xxx in
every statement instead of just dao.

similar code in Visual Basic 2005 is :
Function getrecordcount(ByVal strTableName As String) As Long
Dim dbEngine As Microsoft.Office.Interop.Access.Dao.DBEngine
Dim db As Microsoft.Office.Interop.Access.Dao.Database
dbEngine = New Microsoft.Office.Interop.Access.Dao.DBEngine()
db = dbEngine.OpenDatabase("filename.accdb")
Dim rstRecords As Microsoft.Office.Interop.Access.Dao.Recordset
Dim rstRecords2 As Microsoft.Office.Interop.Access.Dao.Recordset2
rstRecords = db.OpenRecordset("strTableName", dbOpenForwardOnly)
rstRecords2 = db.OpenRecordset("strTableName", dbOpenForwardOnly)

and dbOpenForwardOnly generates a compile error of "is not declared"
while
Microsoft.Office.Interop.Access.Dao.RecordsetTypeEnum.dbOpenForwardOnly works
perfectly.

any ideas why dao. naming convention don't work ?
and why constants like dbOpenForwardOnly don't work ?
and why long naming like
Microsoft.Office.Interop.Access.Dao.RecordsetTypeEnum.dbOpenForwardOnly
is required ?

thanks

I do have the Microsoft Office 12.0 Access database engine Object Libary
added in Visual Basic 2005.
in VBA this object libary is located as c:\Program Files\Common
Files\Microsoft Shared\Acedao.dll
in VB 2005 it has a path of
c:\windows\assembly\GAC\Microsoft.Office.Interop.Access.Dao\12.0.0.__71e9bce111e9429c\Microsoft.Office.Interop.Access.Dao.dll

"Dustin Pedroia" <DustinPedroia.RemoveThis@discussions.microsoft.com> wrote in message
news:A43329EF-4DFD-43CE-B81F-05B2C9354B9C@microsoft.com...
> while using an Access 2007 .accdb file I can access the dao. object very
> easily.
> the following code in VBA works well :
> Function getrecordcount(strTableName As String) As Long
> Dim dbCurrent As DAO.Database
> Set db = CurrentDb
> Dim rstRecords As DAO.Recordset
> Dim rstRecords2 As DAO.Recordset2
> Set rstRecords = db.OpenRecordset(strTableName, dbOpenForwardOnly)
>
> all the DAO.xxx references are recognized and are generated from the
> Microsoft Office 12.0 Access database engine Object Library, acedao.dll
> as evidenced by the ability to reference Recordset2.
>

Yep. That's because MSAccess is doing magic behind your back. When using an
ACCDB file within Access VBA - VBA "DAO" to the ACEDAO library (ACEDAO.DLL).

Now if you opened a MDB file in Access VBA, VBA would see it as the original
DAO library (DAO360.DLL).

Magic. <g>


> but when similar code is generated in Visual Basic 2005 I am unable to
> access the dao. object library using the same dao. naming conventions.
for
> some reason it forces me to use Microsoft.Office.Interop.Access.Dao.xxx in
> every statement instead of just dao.
>

This is because from a managed enviroment you have to use Interop or "COM".
Frankly I haven't played MS 2007 so I'm not sure what happens - I think it
would have to map to acedao, but ???? I don't know for sure.

So far it has been my experience that using Interop is often different than
using the COM components directly. Simply because you are dealing with a
Fascade or Bridge - or perhaps more loosely put - a Wrapper. ie, someone had
to set down and write it and it is not a one-to-one straight conversion.

However, for better information you should post to a dotNet newsgroup, or
perhaps to an MSAccess developers group.

hth
-ralph