dao to ado??

[wshs1]

i've created a simple monitoring system using access(vba).

my network tech is asking if i've done it in dao or ado?

how do i check that?

 

[lameid]

Assuming you designed the database in Access 2000 or later and used the defaults, I'd say ADO if at all. If '97 or later it is definitely DAO as ADO was added in 2000. But I'm not going to leave you hanging, you can check it, see below.

Read this entire post before begining!

First make sure your modules compile.
You can check by designing any module and going to the tools menu and selecting references. If "Microsoft DAO 3.6 Object Library" (or something similar) is checked then you may have used DAO. To be absolutely sure, uncheck it (make a note as to the exact name you will have to check it later, unchecked items are at the bottom of the list in alphabetical order). Hit ok and compile your modules again. If you get an error, you use DAO if not, you probably don't. At any rate you can recheck it after you know.

Similarly you can perform the same test for ADO by looking for the reference "Microsoft ActiveX Data Objects 2.5 Library" (or soemthing similar).

The catch here is you may have BOTH. If you do the order of the references matters. Access will look for objects in whichever library is listed first, first unless the library is specified. Both libraries have a Recordset object. in this case, your code MAY compile if you remove one reference. It is doubtful but possible.

So the below line could be DAO or ADODB...

Dim RS as Recordset

On the other hand the library can be specified:

Dim RS as DAO.Recordset 'This is DAO

Dim RS as ADODB.Recordset 'This is ADO

Another way to look at it is that DAO uses objects like workspaces and databases where ADO uses objects like Projects and Connections.

I hope that helps.

 

[fneily]

You coded and you don't know if you're using DAO or ADO?? Interesting.
When you DIM any variables, did you use the letters DAO, such as DAO.Recordset?
Did you use in your DIM statement ADODB.Recordset? Did you DIM ADO variables for the name of the connection? eg. did you have something like
CurConn.Provider = "Microsoft.Jet.OLEDB.4.0" (that's needed for ADO)
Or maybe you're really doing simplistic coding and using neither.
Maybe you can post some of your code.

 

[wshs1]

thank you. definately helped.

 

[JoeAtWork]

If you have any bound forms at all then you are using DAO.

If you used ADO you would have had to explicitly declare it in your code. And since you don't know what you used, I'm guessing you didn't.

 

[fdcusa]

Here is a simple routine that will show you all the references you have active in an mdb. Copy it into a module and run from the VB window:

Option Compare Database
Option Explicit


'[URL unfurl="true"]http://www.utteraccess.com/forums/showflat.php?Cat=&Number=1253284&page=&view=&sb=5&o=&fpart=1&vc=1[/URL]

Function fRefsOK() As Boolean
    Dim db As Database
    Dim ref As Reference
    Dim strRef As String
    Dim strRefs As String
    Dim intCount As Integer
    Dim intBroken As Integer
    Dim strPad As String
    Set db = CurrentDb
    For Each ref In Application.References
        On Error Resume Next
        strRef = ref.Name & " "
        strRef = strRef & " " & ref.Major
        strRef = strRef & "." & ref.Minor
        strPad = String(30 - Len(strRef), " ")
        strRef = strRef & strPad
        If ref.IsBroken Then
            strRef = strRef & ";Broken"
            intBroken = intBroken + 1
        Else
            strRef = strRef & ";Present"
        End If
        strRefs = strRefs & strRef & vbCrLf
    Next
    fRefsOK = intBroken = 0
    intCount = Application.References.Count
    If MsgBox(intCount & " Application References" & vbCrLf & intBroken & " Broken" & vbCrLf & vbCrLf & _
        "Do you want to see a list?", vbYesNo) = vbYes Then
        MsgBox Replace(strRefs, " ", "  ")
    End If
    Debug.Print "Current Project Information:"
    Debug.Print String(80, "-")
    Debug.Print "Name                  :" & CurrentProject.Name
    Debug.Print "Full Name             :" & CurrentProject.FullName
    Debug.Print "Base Connection String:" & CurrentProject.BaseConnectionString
    Debug.Print "Connection            :" & CurrentProject.Connection
    Debug.Print "File Format           :" & CurrentProject.FileFormat
    Debug.Print "Is Connected?         :" & CurrentProject.IsConnected
    Debug.Print "Parent                :" & CurrentProject.Parent
    Debug.Print "Path                  :" & CurrentProject.Path
    Debug.Print "Type                  :" & CurrentProject.ProjectType
    'Debug.Print strRefs
End Function

 

[lameid]

Contrary to JoeAtWork's post, you do not have to use DAO to have bound forms.

If you referenced the forms recordset, it definitely returned a DAO recordset in Access 2000. I suspect it may be the same in 2003. It just hasn't come up for me.

 

[JoeAtWork]

---> you do not have to use DAO to have bound forms

I tried the following code in an Access2003 bound form and got Error 13 Type Mismatch:

Private Sub Command2_Click()
    Dim rs As ADODB.Recordset
    
    Set rs = Me.Recordset
    
End Sub

So the form's recordset is still DAO.

Interestingly, after I removed both the DAO and ADO references, the bound form continued to work. I think we can conclude from this that the references we set through the VBA IDE has nothing to do with what Access references internally.

I'm quite sure that if you're using Access, you're using DAO. Uninstall DAO from your computer and I doubt that Access will start up. I'd be quite surprised to find out that all the internal routines in Access, including accessing the system tables, uses anything other than DAO.

 

[lameid]

Even if Access uses DAO, I think the purpose of the question is to determine whether the code he wrote is DAO or ADO. That may determine future upgrade paths for office in the future. Assuming Access 2003 uses DAO native and 2007 will use ADO native, that has nothing to do with whether an ADO only procedure will compile and execute.

If I were a tech and I wanted to know if uninstalling DAO would break something, I would uninstall it and test it or at least ask the developer to test on a test machine. If what you are saying is true about native Access code then uninstalling DAO library breaks a widely deployed program, and the tech is not going to end up doing it anyways.

 

[jsteph]

my network tech is asking if i've done it in dao or ado?

Why is the network tech asking? If he's asking out of friendly curiosity--fine. But I've seen too many 'network guys' who want to play god and dictate to developers how to do their job.

What does it have to do with him? If he mutters something about 'bandwidth' or whatever, tell him phooey.

It sounds like he's throwing out buzzwords. Tell him it's done in FBI,CIA, NBC--it really has no bearing on him. It's a programming construct and a decently written DAO Access app will not have appreciably more bandwidth usage than an ADO app--in fact it could have less, depending on how poorly the ADO is written.

Bottom line--it's none of the network guy's business.
--Jim

 

[lameid]

Jim,

I mostly agree with you. However Microsoft has said it is going to do away with DAO at some point. A network tech who is really on the ball would want to know what will need to be touched if a future upgrade kills DAO. Microsoft recommends not to use DAO. Similarly if there is a security issue exploiting DAO, it would be useful to know if it is acceptible to make a Group Policy to eliminate DAO support (probably a couple options here but alas my knowlege of Group Policy is more conceptual than practical). This is shakier ground here. I would not do it but my managers were reluctant to buy our first firewall so security is not as great a concern as it is for others.

Because of the planned obsolecence of DAO, maybe his company has a policy to only use ADO and it is the Tech's job to ferret out 'abusers'.

If you have ever been a tech, you know you don't want to be on the receiving end of why did the upgrade break my App? Didn't you test it?

 

[jsteph]

lameid,
I suppose it depends on the company.

Where I'm at the network techs deal with routers, domain servers, security issues etc. They never set policy on application software upgrade paths in any way, shape or form.

The PC techs, a slightly different breed, deal with installing the OS, building PC's, fixing printer issues, etc. They do have a say in the OS upgrade paths but only a say.

OS upgrade paths and platforms are discussed as a committe (lead developer, lead PC tech, lead network tech, and the IT Manager) and we come up with a direction, but this is a relatively static thing--it's not like one week we up and say "hey, let's go Linux".

But meetings discussing development tools & techniques rarely include PC techs or network people, unless we have a specific question for them about bandwidth, security, etc.

Having a network tech telling me I should use DAO instead of ADO or vice-versa would be like me telling him he should use a Cisco 3825 router instead of a 3845--what the heck do I know--and even if I was knowledgeable about that, we like to have a well oiled machine where I stay out of their specific business and they stay out of mine.
--Jim