Results 1 to 7 of 7
  1. #1
    3 Star Lounger
    Join Date
    Feb 2001
    Posts
    369
    Thanks
    2
    Thanked 1 Time in 1 Post

    Mixing DAO and ADO (2000sp3)

    I have some bits of stock code that I'd like to use in a database that's been written, by someone more up to date than I, using ADO. I've never used ADO, and really don't have the time to learn right now. All my objects are explicitly declared as DAO, and I've added a reference to DAO to the db, but left it below ADO in the ref list, as I don't know if all the ADO objects were explicitly declared as such.

    Can I expect problems? Will they be easily traceable, or is it more likely to be a case of weird and unpredictable behaviour.

    Thanks

  2. #2
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Re: Mixing DAO and ADO (2000sp3)

    I think you'll be OK. Since ADO is above DAO in the references list, VBA will use ADO for ambiguous objects that have not been declared as ADO or DAO explicitly. Even if the other developer has not explicitly declared his objects as ADO, they will still be interpreted as ADO objects. Your code does explicitly declare objects as DAO, so there should be no problem with them.

    Of course, you could search the project for ambiguous declarations, by looking for As Recordset and As Field, to name the most obvious ones.

  3. #3
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Mixing DAO and ADO (2000sp3)

    In addition to Hans suggestions, do NOT try to mix DAO and ADO in the same routine. In other words, don't try to call ADO code from a DAO routine and vice versa. It sometimes is OK and other times dumps you unceremoniously back to the desktop without even the courtesy of an error message. I've built projects using both models, but I learned early to avoid mixing them in a single routine.
    Charlotte

  4. #4
    3 Star Lounger
    Join Date
    Jan 2001
    Location
    Newbury, Berkshire, UK, Berkshire, England
    Posts
    243
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Mixing DAO and ADO (2000sp3)

    I also try to make sure I disambiguate any object references, e.g.
    Dim Rst1 As ADODB.Recordset
    Dim Rst2 As DAO.Recordset

    - oh, just upgraded to Access 2003 and now the default references in a new database include DAO and second ADO

  5. #5
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Mixing DAO and ADO (2000sp3)

    Yes, even though Microsoft has declared DAO obsolete, they seem to have recognized that ADO isn't suited to handle the application objects the way DAO is and so they have resuscitated it in 2003. Including both references means that disambiguating your declarations is NOT an option, it is absolutely vital. Oh, and you still can't interact between DAO and ADO objects, so don't try it.
    Charlotte

  6. #6
    3 Star Lounger
    Join Date
    Feb 2001
    Posts
    369
    Thanks
    2
    Thanked 1 Time in 1 Post

    Re: Mixing DAO and ADO (2000sp3)

    Thank you all for your reassurance.

    Just to clarify, Charlotte, when you talk about a DAO routine calling ADO code, you're referring to "built in" code: if a user written sub routine using ADO calls a user written function which uses DAO it should be OK? This is the situation I have, as my stock bits of code are called regularly (one is a custom message box function, for instance).

    Thanks again

  7. #7
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Mixing DAO and ADO (2000sp3)

    No, it may not be OK. If all you're doing is popping up a messagebox, it will be OK because those are built-in VBA functions rather than DAO or ADO. But you can't mix objects. ADO Table objects are not the same as DAO TableDef objects, for instance, and you can't manipulate them the same way. You can't use a DAO recordset to perform manipulations with ADO. Interface objects like forms and controls are not object model specific, but the way you interact with them through code is. The Forms collection and the AllForms collection don't have the same methods and properties. The former is used with DAO and the latter with ADO.
    Charlotte

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •