Does Visual Basic support Data Access Objects (DAO)?

Hi all

I'm a newbie to Visual Basic Express 2005. I have a bunch of working modules in Access VBA which I'd like to port to Visual Basic Express 2005 and a separate MDB file. But I don't seem to see any reference in Visual Basic Express for DAO 3.6.

I suppose I could rewrite the code for ADO but it's going to takeA LOT of rewriting. I'm already adapting some of the code to VBE2005 norms so I don't want to incurr any more rewriting than I have to.

Does VBE2005 support DAO? If so, how? Or am I better off keeping and running these modules in Access?

Any help appreciated.

Thanks!

[638 byte] By [Rick.B] at [2008-1-10]

«« Statment reached after persisted Yield
»» EnumChildWindows and modal dialogs

# 1

Project + Add Reference, COM tab, select "Microsoft DAO 3.6 Object Library". You'd code it like this:

Imports dao

Public Class Form1
Dim mEngine As DBEngine = New DBEngine()

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
Dim db As Database = mEngine.OpenDatabase("c:\boss36\data.mdb")
Dim rs As Recordset = db.OpenRecordset("select * from [glass types] order by glassid", _
RecordsetTypeEnum.dbOpenForwardOnly, RecordsetOptionEnum.dbSeeChanges, _
LockTypeEnum.dbOptimistic)
Do Until rs.EOF
Console.WriteLine(CStr(rs.Fields("glassid").Value))
rs.MoveNext()
Loop
rs.Close()
End Sub
End Class

I doubt that's what you're looking for, the late bound "rs!glassid" doesn't work. I don't think DAO is distributed anymore, you might want to switch to OleDB after all.

nobugz at 2007-10-3 >

top of Msdn Tech,Visual Basic,Visual Basic General...

# 2

The other poster has exactly what I would've posted, and I can't add much other than two things:

1) I've been using DAO with every .NET project since 2002, if for no other reason than I prefer using Access databases for lightweight data access projects and periodic compression at runtime is a must to keep those sizes low.

2) For what it's worth, I loved DAO and had a hard time giving it up. The transition to ADO is really, really similar though, and IMO far, far easier to deal with than the DataAdapter etc. craziness that seems to be the norm nowadays.

So there's my $0.02.

JasonPayne at 2007-10-3 >

# 3

Thanks for the background, Jason.

I've been practicing with ADO but it is no advantage over DAO performance wise. A couple of times I ran a module in Microsoft Access using ADO and then again using DAO. DAO significantly beat ADO EVERY TIME! Even indexing the fields didn't help ADO one bit but caused DAO to take-off even faster!!!

From what I can tell DAO uses the excellent JET database engine while ADO uses something generic. I can't understand Microsoft's thinking in this regard.

Rick.B at 2007-10-3 >

# 4

Oh, is that how it is turned-on? Cool!

Thanks Hans. I appreciate the code example too. It is something to work with.

Much appreciated!

Rick.B at 2007-10-3 >

# 5

Huh; I've always wanted to do a performance comparison between the two techs! Good to know.

For what it's worth, I think the thinking behind ADO vs. DAO is that the latter, while we both agree is pretty cool and speedy, is tied strictly to Access databases IIRC. Jet can't connect to Oracle or other ODBC-compliant RDBMSs, unless I missed something. So it makes sense that a streamlined, proprietary connection tech is going to have some performance benefits over obsessively abstracted managed data layers designed to support any connection.

The performance tradeoff is no problem for folks who want to be able to change data source techs without recoding everything. For example, Jet/DAO can't connect to an XML file for data access! Smile

JasonPayne at 2007-10-3 >

Visual Basic

Visual Basic General

Visual Basic Hot Topic

Visual Basic New Topic

Visual Basic

Java / MSDN / Linux Tech / PHP Tech / MSDN DotNet / MSDN TECH / Health Library / Programmers Tech / visual basic Tech / Developer Tech / Ipod faqs / Msdn China Tech