Results 1 to 14 of 14

Thread: ADO, DAO v MOAL for desktop Access applications

  1. #1

    Thread Starter
    New Member
    Join Date
    Oct 2017
    Posts
    4

    ADO, DAO v MOAL for desktop Access applications

    If developing desktop applications in Access, why would you want to use ADO or DAO, rather than builtin MOAL?

  2. #2
    Frenzied Member
    Join Date
    Jun 2014
    Posts
    1,084

    Re: ADO, DAO v MOAL for desktop Access applications

    What is MOAL ???
    do not put off till tomorrow what you can put off forever

  3. #3
    PowerPoster ChrisE's Avatar
    Join Date
    Jun 2017
    Location
    Frankfurt
    Posts
    3,046

    Re: ADO, DAO v MOAL for desktop Access applications

    Quote Originally Posted by IkkeEnGij View Post
    What is MOAL ???
    I would like to know that too

    regards
    Chris
    to hunt a species to extinction is not logical !
    since 2010 the number of Tigers are rising again in 2016 - 3900 were counted. with Baby Callas it's 3901, my wife and I had 2-3 months the privilege of raising a Baby Tiger.

  4. #4

    Thread Starter
    New Member
    Join Date
    Oct 2017
    Posts
    4

    Re: ADO, DAO v MOAL for desktop Access applications

    Quote Originally Posted by ChrisE View Post
    I would like to know that too

    regards
    Chris
    Sorry, should be MAOL (Microsoft Access Object Library).

  5. #5

    Thread Starter
    New Member
    Join Date
    Oct 2017
    Posts
    4

    Re: ADO, DAO v MOAL for desktop Access applications

    Perhaps I should make things clearer.
    From within one Access database, I want to be able to programmatically (vba):
    1. create another Access database
    2. create several tables within that new database
    3. populate those new tables using data from tables within the original database
    4. report using those new tables within the new database
    5. finally, delete the new database.

    So far, by experiment, I can do 1, 2 and 5 with just the References:
    Visual Basic For Applications,
    Microsoft Access 16.0 Object Library,
    Microsoft Office 16.0 Access database engine Objects.

    No other References seem needed, in particular no ADO (or DAO).

    Assuming that with enough effort I can also do 3 and 4 with no further References,
    my question is Why, for the desktop, would anyone bother with ADO (or DAO)?

    Regards,
    AccLearn

  6. #6
    King of sapila
    Join Date
    Oct 2006
    Location
    Greece
    Posts
    6,597

    Re: ADO, DAO v MOAL for desktop Access applications

    The question is why would anyone bother with Access?
    ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς μάλα πολλὰ
    πλάγχθη, ἐπεὶ Τροίης ἱερὸν πτολίεθρον ἔπερσεν·

  7. #7
    PowerPoster ChrisE's Avatar
    Join Date
    Jun 2017
    Location
    Frankfurt
    Posts
    3,046

    Re: ADO, DAO v MOAL for desktop Access applications

    Quote Originally Posted by AccLearn View Post
    Perhaps I should make things clearer.
    From within one Access database, I want to be able to programmatically (vba):
    1. create another Access database
    2. create several tables within that new database
    3. populate those new tables using data from tables within the original database
    4. report using those new tables within the new database
    5. finally, delete the new database.

    So far, by experiment, I can do 1, 2 and 5 with just the References:
    Visual Basic For Applications,
    Microsoft Access 16.0 Object Library,
    Microsoft Office 16.0 Access database engine Objects.

    No other References seem needed, in particular no ADO (or DAO).

    Assuming that with enough effort I can also do 3 and 4 with no further References,
    my question is Why, for the desktop, would anyone bother with ADO (or DAO)?

    Regards,
    AccLearn
    Hi,

    regarding 2.) / 3.)

    Code:
      
     Export to MDB
    'change the name Tabelle1A to the tablename you need
        sSQL = "SELECT * INTO Tabelle1A IN 'c:\test\mike.mdb' FROM Tabelle1A;"
    
          Import to other MDB
        sSQL = "Select * Into Tabelle1C From Tabelle1A In 'c:\test\mike.mdb'"
    
    then execute the sSQL statment
    regards
    Chris
    Last edited by ChrisE; Oct 23rd, 2017 at 01:52 AM.
    to hunt a species to extinction is not logical !
    since 2010 the number of Tigers are rising again in 2016 - 3900 were counted. with Baby Callas it's 3901, my wife and I had 2-3 months the privilege of raising a Baby Tiger.

  8. #8
    Don't Panic! Ecniv's Avatar
    Join Date
    Nov 2000
    Location
    Amsterdam...
    Posts
    5,343

    Re: ADO, DAO v MOAL for desktop Access applications

    ADO
    if in the future you want to change to sql server or some other database for the tables

    dao
    because its internal and tweaked to access dbs

    MAOL
    is just the object library and not really to do with the data


    As to sapators comment

    access can be used to create a quick solution or to try something out before putting into a bigger db, say ms sql server.
    From my experience lead times on the bigger databases are a lot longer than ms access dev and for putting a case forward to a bigger database, you can make the solution quickly in access.

    If you happen to be lucky enough that you have ms sql/oracle or some othe big db that you can make up solutions quickly and that may or may not be used afterwards... good for you.

    BOFH Now, BOFH Past, Information on duplicates

    Feeling like a fly on the inside of a closed window (Thunk!)
    If I post a lot, it is because I am bored at work! ;D Or stuck...
    * Anything I post can be only my opinion. Advice etc is up to you to persue...

  9. #9
    Frenzied Member
    Join Date
    Jun 2014
    Posts
    1,084

    Re: ADO, DAO v MOAL for desktop Access applications

    Quote Originally Posted by AccLearn View Post
    Perhaps I should make things clearer.
    From within one Access database, I want to be able to programmatically (vba):
    1. create another Access database
    2. create several tables within that new database
    3. populate those new tables using data from tables within the original database
    4. report using those new tables within the new database
    5. finally, delete the new database.

    So far, by experiment, I can do 1, 2 and 5 with just the References:
    Visual Basic For Applications,
    Microsoft Access 16.0 Object Library,
    Microsoft Office 16.0 Access database engine Objects.

    No other References seem needed, in particular no ADO (or DAO).

    Assuming that with enough effort I can also do 3 and 4 with no further References,
    my question is Why, for the desktop, would anyone bother with ADO (or DAO)?

    Regards,
    AccLearn
    https://msdn.microsoft.com/en-us/vba...-method-access
    do not put off till tomorrow what you can put off forever

  10. #10
    Fanatic Member Spooman's Avatar
    Join Date
    Mar 2017
    Posts
    868

    Re: ADO, DAO v MOAL for desktop Access applications

    Quote Originally Posted by Ecniv View Post
    ADO
    if in the future you want to change to sql server or some other database for the tables

    dao
    because its internal and tweaked to access dbs

    MAOL
    is just the object library and not really to do with the data
    Nice summary.
    I support DAO ..

  11. #11
    Frenzied Member
    Join Date
    Jun 2014
    Posts
    1,084

    Re: ADO, DAO v MOAL for desktop Access applications

    Quote Originally Posted by AccLearn View Post
    Microsoft Office 16.0 Access database engine Objects.
    No other References seem needed, in particular no ADO (or DAO).
    this just occured to me:
    i may be wrong, but:
    i am willing to bet a box of chocolates thats all you need to use DAO
    have you tried ?
    do not put off till tomorrow what you can put off forever

  12. #12

    Thread Starter
    New Member
    Join Date
    Oct 2017
    Posts
    4

    Re: ADO, DAO v MOAL for desktop Access applications

    dao
    because its internal and tweaked to access dbs

    MAOL
    is just the object library and not really to do with the data


    Please, what does DAO provide that MAOL doesn't?

    Regards,
    AccLearn

  13. #13
    Don't Panic! Ecniv's Avatar
    Join Date
    Nov 2000
    Location
    Amsterdam...
    Posts
    5,343

    Re: ADO, DAO v MOAL for desktop Access applications

    Have you opened up the intellisense on them ?

    DAO (Data Access Objects if I remember right) does all the recordset and query type things.. ie data movement.

    I think that the MAOL is the structures to show, like or database containers, form controls.

    But since I used to just use the default (only adding in the DAO if the default was ADO) and used the internal DAO recordsets etc, I never looked at the MAOL. Just use what you need and think what you may need in the future. ie - if its only going to stay access, use the forms and dao etc internal. if you are going to change backends to excel, mysql, sql server, oracle or some other db, use ado as its a little easier to transfer.

    This is my opinion ofcourse, pinch of salt. Worth trying out as many different ways to do things so YOU know why you did it a specific way.



    To test the bits selected try: go to the vb editor (ctrl+g) press f2
    This should open a list of all objects referenced. you can go through the listing to see whats available. Notice that DAO has only data type objects, `Access` has the forms, database containers etc...

    Hope that helps

    BOFH Now, BOFH Past, Information on duplicates

    Feeling like a fly on the inside of a closed window (Thunk!)
    If I post a lot, it is because I am bored at work! ;D Or stuck...
    * Anything I post can be only my opinion. Advice etc is up to you to persue...

  14. #14
    Frenzied Member
    Join Date
    Jun 2014
    Posts
    1,084

    Re: ADO, DAO v MOAL for desktop Access applications

    Quote Originally Posted by AccLearn View Post
    ]Please, what does DAO provide that MAOL doesn't?
    well, for one, it enables other programs to work (among others) with access databases, without using MSaccess (the program)
    but i think you do not really understand what you are referencing
    you DO have a reference to DAO (in your particular case to ACEDAO)
    DAO is what is in 'Microsoft Office 16.0 Access database engine Objects'

    try the following:
    in an access module insert the following code:
    Code:
    Sub DAOtest()
        Dim db As DAO.Database
        Dim rs As DAO.Recordset
        Dim TDef As DAO.TableDef
        Dim Fld As DAO.Field
        Set db = CurrentDb
        Debug.Print db.Name
        Debug.Print String(Len(db.Name), "=")
        For Each TDef In db.TableDefs
            Debug.Print "-"; TDef.Name; "-"
            For Each Fld In TDef.Fields
                Debug.Print " "; Fld.Name
            Next
            Debug.Print
        Next
    End Sub
    run it and see what happens
    now, remove the reference to Microsoft Office 16.0 Access database engine Objects
    run it, what happens now ?

    you see ?, you have a formidable tool (DAO) in your toolbox
    whether you use it or not...that's up to you

    btw: did this in access2010 ... i have no access (pun intended) to access2016
    do not put off till tomorrow what you can put off forever

Posting Permissions

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



Click Here to Expand Forum to Full Width