Results 1 to 5 of 5
  1. #1
    4 Star Lounger
    Join Date
    Apr 2001
    Location
    Guatemala City
    Posts
    515
    Thanks
    0
    Thanked 0 Times in 0 Posts

    DAO/ADO (Win ME/Access 97)

    I see references to DAO and to ADO. Could someone explain what this is about? My references have checked:

    Visual Basic For Applications
    Microsoft Access 8.0 Object Lib
    Microsoft DAO 2.5/3.5 Compatability Lib
    Utility

    There is an unchecked Microsoft DAO 3.51 Object Lib.

    I don't know the logic of why one or the other is checked or not. Things just came that way with the instalation, I guess.

    I see references to declaring objects as DAO.Database and DAO.Recordset. I don't know enough about this to even phrase a question.

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

    Re: DAO/ADO (Win ME/Access 97)

    Just to add my <img src=/S/2cents.gif border=0 alt=2cents width=15 height=15> to Hans' comprehensive reply, both DAO and ADO have some objects with the same names. These include recordsets, parameters, indexes, fields, connections, properties, and several more I can't recall at the moment. However, the methods and properties of these objects are not the same in the two different object models. So if you simply dim a recordset, Access has to guess at the object model and it has an even chance of guessing wrong if you have both references set. On the other hand, ADO does NOT have any objects for database, querydef, tabledef, etc. So if you don't have the DAO object model checked in Access 2000 and later, those objects will not be recognized and you'll get an error.

    The odds are that sooner or later you'll wind up using a later version of Access. Explicitly declaring object variables with the object model included (DAO.Recordset, ADODB.Connection, etc.) will eliminate some potential errors, make debugging much easier later and will help keep you from accidentally mixing the two object models, a situation that can cause Access to terminate abruptly without even the courtesy of an error message.
    Charlotte

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

    Re: DAO/ADO (Win ME/Access 97)

    In Access 97, the standard object model for data objects (tables, queries, recordsets, fields, ...) is DAO = Data Access Objects. The version of DAO to use for Access 97 is 3.51. The Microsoft DAO 2.5/3.5 Compatibility Library is only meant for databases that have been converted from older versions of Access and use "old fashioned" code. For databases created in Access 97 you should uncheck the 2.5/3/5 Compatibility Library and check the 3.51 Object Library.

    In Access 2000, Microsoft introduced a new object model as standard: ADO = ActiveX Data Objects. While DAO is closely connected to the Jet database engine, ADO is much broader in scope. Although there are many similarities between DAO and ADO, they have substantial differences.

    Access 2000 and XP still support DAO - the version for 2000 (and XP) is 3.6. And it is possible to use ADO in Access 97, although there is no native support for it.

    If you use both ADO and DAO in a database, you have to be careful to distinguish between them. Both object models have objects such as Recordset, but they have different properties and methods, so if you refer to a Recordset without being specific, you may get unexpected results. That's why it is useful to declare recordsets in Access 2000 and XP with an explicit reference to the object library: Dim rst As DAO.Recordset or Dim rst As ADODB.Recordset.

    If you're programming in Access 97, strictly speaking you don't need to do this. But chances are that you will have to convert your database to Access 2000 or XP sometime in the future. To save yourself trouble and a lot of work then, it is wise to start being explicit in Access 97 now.

  4. #4
    4 Star Lounger
    Join Date
    Apr 2001
    Location
    Guatemala City
    Posts
    515
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: DAO/ADO (Win ME/Access 97)

    Thank you. Obviously it is easier to add the DAO now, rather than waiting until some later date. I am reviewing and modifying my current project to do that. When I add the DAO to the recordset Dim statement (MyTerreno As DAO.Recordset) everything seems to function OK. I am also changing the Dim statement on the Dim of a Database as follows : (Dim MyDb As DAO.Database).

    I have seen some code with the statement (Dim dbe As DAO.DBEngine). Then later the Set statement (Set dbe = CreatObject("DAO.DBEngine.35")). What is going on there?

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

    Re: DAO/ADO (Win ME/Access 97)

    In Access 97, by default you have a reference to DAO, and not to ADO. In that setting, Dim rst As Recordset and Dim rst As DAO.Recordset are fully equivalent, and there is no danger of confusion. Code should run OK with or without the DAO prefix. But if you convert an Access 97 database to Access 2000, you risk confusion if you used Dim rst As Recordset, because it might be created as an ADO recordset instead of a DAO recordset, and then DAO methods will fail.

    Code with CreateObject is used to control one application from another one. In Access itself, it shouldn't be necessary to create a DBEngine object, because it is created when you start Access. But if you want to manipulate a database from, say, Word or Excel, you can obtain access to DAO objects this way. If you have different versions of the database engine installed on your PC, you can create an object of a specific version: CreateObject("DAO.DBEngine.35"), i.e. version 3.5 for Access 97) or CreateObject("DAO.DBEngine.36"), i.e. version 3.6 for Access 2000. Unless you really need this, I wouldn't bother with this now.

Posting Permissions

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