-
Oct 21st, 2017, 04:24 PM
#1
Thread Starter
New Member
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?
-
Oct 21st, 2017, 10:27 PM
#2
Re: ADO, DAO v MOAL for desktop Access applications
do not put off till tomorrow what you can put off forever
-
Oct 22nd, 2017, 02:06 AM
#3
Re: ADO, DAO v MOAL for desktop Access applications
Originally Posted by IkkeEnGij
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.
-
Oct 22nd, 2017, 02:38 AM
#4
Thread Starter
New Member
Re: ADO, DAO v MOAL for desktop Access applications
Originally Posted by ChrisE
I would like to know that too
regards
Chris
Sorry, should be MAOL (Microsoft Access Object Library).
-
Oct 22nd, 2017, 03:37 PM
#5
Thread Starter
New Member
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
-
Oct 22nd, 2017, 04:47 PM
#6
Re: ADO, DAO v MOAL for desktop Access applications
The question is why would anyone bother with Access?
ἄνδρα μοι ἔννεπε, μοῦσα, πολύτροπον, ὃς μάλα πολλὰ
πλάγχθη, ἐπεὶ Τροίης ἱερὸν πτολίεθρον ἔπερσεν·
-
Oct 23rd, 2017, 01:46 AM
#7
Re: ADO, DAO v MOAL for desktop Access applications
Originally Posted by AccLearn
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.
-
Oct 23rd, 2017, 01:57 PM
#8
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.
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...
-
Oct 23rd, 2017, 02:11 PM
#9
Re: ADO, DAO v MOAL for desktop Access applications
Originally Posted by AccLearn
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
-
Oct 23rd, 2017, 03:18 PM
#10
Re: ADO, DAO v MOAL for desktop Access applications
Originally Posted by Ecniv
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 ..
-
Oct 23rd, 2017, 04:18 PM
#11
Re: ADO, DAO v MOAL for desktop Access applications
Originally Posted by AccLearn
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
-
Oct 24th, 2017, 03:59 AM
#12
Thread Starter
New Member
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
-
Oct 24th, 2017, 10:25 AM
#13
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
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...
-
Oct 24th, 2017, 03:08 PM
#14
Re: ADO, DAO v MOAL for desktop Access applications
Originally Posted by AccLearn
]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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|