Results 1 to 5 of 5
  1. #1
    kitT
    Guest

    DAO to ADO (2k) (Access 2000)

    Is it worth updating code in a database converted up a couple of times from Access (first version) through to Access 2000, rewriting any old DAO code as ADO? I recreate the database every couple of years to "clean it out" by importing the data, forms, reports etc into a new db. It is getting quite large, would it run more smoothly and chew up less memory if I rewrote the old code?

  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 to ADO (2k) (Access 2000)

    Depending on how old the database is in terms of versions, it might benefit you to rewrite some of the code to bring your DAO up to date, but there isn't much point in changing everything to ADO if you're using a Jet backend. In that case, the DAO is probably going to be faster. The only reason to add ADO code would be to take advantage of some of the new features that require it, like persisted or disconnected recordsets.
    Charlotte

  3. #3
    kitT
    Guest

    Re: DAO to ADO (2k) (Access 2000)

    Thanks, Charlotte, I take it you view DAO code as better (faster etc), but perhaps not as flexible - is this right?

    I have both DAO and ADO libraries referenced, with DAO given priority - is this the best thing to do in the circumstances?

    Also, can you expand on:
    "The only reason to add ADO code would be to take advantage of some of the new features that require it, like persisted or disconnected recordsets."

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

    Re: DAO to ADO (2k) (Access 2000)

    No, I use ADO primarily, but I don't go back and rewrite functional code to use ADO because there isn't any point in it. DAO *is* faster for some Jet-only related operations. DAO is Jet-specific, so it isn't surprising that some operations are faster in it. ADO relies on each provider for its methods and properties and doesn't have the built-in economies of DAO.

    However, the two object models are only superficially similar. DAO is designed to handle Access/Jet data. It works slowly on other kinds of data and it can't handle anything that can't be coerced into a table format. ADO is generally faster when handling non-Jet data sources and can handle all kinds of sources, not just tables. Plus it can directly manipulate data and objects in sources that are not *linked* to the current database.

    If you haven't explored ADO, then any explanation of persisted recordsets and disconnected recordsets would be meaningless. The ADO object model is not as linear as the DAO model. You can create a recordset object and then attach a connection to it or attach it to a command object or simply pass it an existing recordset. You can also open a recordset and then close the connection, leaving the recordset "disconnected" but still functional. It's a whole different programming approach and it takes some getting used to.
    Charlotte

  5. #5
    kitT
    Guest

    Re: DAO to ADO (2k) (Access 2000)

    Thank you, as always, a wonderful response. <img src=/S/bow.gif border=0 alt=bow width=15 height=15>

    I will explore ADO when I have more time. Meanwhile I'll putter along with the current rather mixed up apps <img src=/S/wink.gif border=0 alt=wink width=15 height=15>

Posting Permissions

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