DAO references / 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

date: Wed, 27 Feb 2008 11:58:04 -0800   author:   Dustin Pedroia

Re: DAO references / Access 2007   

On Wed, 27 Feb 2008 11:58:04 -0800, Dustin Pedroia
 wrote in
:

>while using an Access 2007 .accdb file I can access the dao. object very 
>easily.
>the following code in VBA works well :

[snip code]

>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.

[snip code]

>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 ?

It is required because that is the full namespace of the
class/struct/enum/etc. that you want to reference.  .NET has
namespaces, whereas VBA does not; it has only classes.  Also
enumeration members must be prefixed by their enumeration name.  This
prevents collisions when there are multiple enumerations in a project,
some of which may use the same names for members.

There is, however, a way around the worst of this.  You can use a line
like the following at the top of your source file in C#:

using Dao = Microsoft.Office.Interop.Access.Dao;

I'm not sure what the equivalent VB syntax is.  I would suggest asking
in microsoft.public.dotnet.languages.vb.

Once you've done that, you can type:

Dao.RecordSetTypeEnum.dbOpenForwardOnly

or

Dao.Engine
-- 
Charles Calvert             |  Software Design/Development
Celtic Wolf, Inc.           |  Project Management
http://www.celticwolf.com/  |  Technical Writing
(703) 580-0210              |  Research

date: Mon, 31 Mar 2008 21:57:59 -0400   author:   Charles Calvert