views:

85

answers:

2

I am working with an Access 2003 database that has a subroutine using DAO code. This code loops through the table definitions and refreshes the ODBC connection string. I would like to convert this to ADO so I do not have to reference the DAO object library. Here is the code ...

Public Sub RefreshODBCLinks(newConnectionString As String)

    Dim db As DAO.Database
    Dim tb As DAO.TableDef
    Set db = CurrentDb
    For Each tb In db.TableDefs
        If Left(tb.Connect, 4) = "ODBC" Then
            tb.Connect = newConnectionString
            tb.RefreshLink
            Debug.Print "Refreshed ODBC table " & tb.Name
        End If
    Next tb
    Set db = Nothing

    MsgBox "New connection string is " & newConnectionString, vbOKOnly, "ODBC Links refreshed"

End Sub

The part I am unsure of is how to loop through the tables and get/set their connection strings.

+4  A: 

DAO is really best for that, you cannot refresh the link with ADO rather you would need to use ADOX (Some relevant code here).

You can acces the connection string via Jet OLEDB:Link Provider String

Alex K.
Thanks for the info. Is the ADOX functionality already included in the ADO library? If it is not and I have to reference another library I might as well stay with the DAO code.
webworm
It's another reference to msadox.dll which for me calls itself 'Microsoft ADO Ext. 2.7 for DDL and Security'
Alex K.
ADOX requires a reference to "Microsoft ADO Ext. <version#> for DDL and Security" if you want to use early binding.
HansUp
Thanks Alex. In your opinion would it be better to just stick with the DAO code and reference to the DAO library or would it be better to reference the ADOX library and use the ADOX code?
webworm
DAO has been always been preferred (http://msdn.microsoft.com/en-us/library/aa164825%28office.10%29.aspx)
Alex K.
DAO is preferred for this because a linked table is a Jet/ACE object.
David-W-Fenton
+2  A: 

If avoiding a reference for DAO is your goal, you could just modify your existing procedure to use late binding for DAO. As an example, this sub should work without a reference set for DAO.

Public Sub DAO_without_reference()
    Dim db As Object
    Dim td As Object
    Set db = CurrentDb
    For Each td In db.TableDefs
        Debug.Print td.Name
    Next td
    Set db = Nothing
End Sub

You would not have Intellisense to help you with DAO properties, methods, and constants while writing the code, but the code can still work with late binding.

I think this would be your easiest alternative if you are determined to avoid a DAO reference. However, I have never developed an Access project without a DAO reference, and I don't understand why you are opposed to adding it.

Edit: Also if you use late binding and any DAO constants, your code must use the constant value rather than the name.

HansUp
Thanks HansUp. I am not determined to avoid DAO. Rather, I just want to avoid adding additional references if I can help it. The less dependencies the better. As for DAO, it just that I am more familiar with the ADO library and object model. That being said, a lot of people have suggested DAO is the way to go. Any suggestions on where to find documentation and examples of DAO in use? Almost all the books I have on Access 2003 seem to only discuss ADO.
webworm
@webworm I also try to limit the number of references, but DAO is one I always include. DAO seems the more natural fit with Jet/ACE data sources. You can find DAO code samples in The Access Cookbook (from O'Reilly). Actually when I first started with Access, I chose to focus on ADO but was disappointed that most of the code samples I encountered were DAO. You seem to be in the opposite situation. Try http://www.mvps.org/access/ and http://allenbrowne.com/tips.html
HansUp
Thanks HansUp .. great feedback! One last question. Given that my datastore is SQL Server and that I access all stored procedures from code, would you still go with DAO over ADO? Thanks a bunch.
webworm
Good question. That's a case where I use ADO. (Of course, SQL Server is not a Jet/ACE data source.) Also, ADO for DDL statements because ADO supports more DDL features than DAO. And ADO for other features (disconnected recordsets) which I use infrequently. Overall, probably more than 90% of my Access VBA code uses DAO, <= 10% ADO. For more perspective, search this forum for David Fenton, DAO and ADO. His experience is considerable more extensive than mine.
HansUp
If you're using linked tables to access your data, then DAO is the reference you should be using, and it's ADO you should use with late binding. ADO should be used only rarely, for things things Jet/ODBC can't do well.
David-W-Fenton
David, would you also use DAO to execute server side stored procedures?
webworm