ADO vs. "Native Access"

G

Guest

I'm new to Access 2003...I'm confused about how to interact with Access
tables in Access VBA. When I am writing Access VBA code, do I need to use ADO
(I know the ADO vs. DAO arguments) to interact with my database/tables? Or is
there a [better/easier?] "native Access" way to do this? I know I can issue
SQL commands, but I've also seen a thread or two refer to "native Access"
commands. Simple forms seem avoid any ADO...is that just coded behind the
scenes by Access?

I don't mind using ADO if I have to, but I'm also looking for rapid
development and want to avoid the learning ADO if it isn't needed. I worked
with Access 97 years ago, and I seem to recall being able to do some pretty
detailed Access work without getting into DAO, but my memory may be failing
me.

I hope that makes sense - thanks in advance for the help/patience.
 
G

Guest

The menu commands that you see in Access are 'native', and
they are wrappers to Jet commands. Access may talk directly
to the Jet DLL's, but it mostly seems to be DAO.

Both ADO and DAO are 'native' to Access. You can get DAO
or ADO from the Application object:

(david)
 
D

David C. Holley

ADO is not 'native' to Access. It was originally created as a means to
generically connect to a database.

david@epsomdotcomdotau said:
The menu commands that you see in Access are 'native', and
they are wrappers to Jet commands. Access may talk directly
to the Jet DLL's, but it mostly seems to be DAO.

Both ADO and DAO are 'native' to Access. You can get DAO
or ADO from the Application object:

(david)

I'm new to Access 2003...I'm confused about how to interact with Access
tables in Access VBA. When I am writing Access VBA code, do I need to use
ADO

(I know the ADO vs. DAO arguments) to interact with my database/tables? Or
is

there a [better/easier?] "native Access" way to do this? I know I can
issue

SQL commands, but I've also seen a thread or two refer to "native Access"
commands. Simple forms seem avoid any ADO...is that just coded behind the
scenes by Access?

I don't mind using ADO if I have to, but I'm also looking for rapid
development and want to avoid the learning ADO if it isn't needed. I
worked

with Access 97 years ago, and I seem to recall being able to do some
pretty

detailed Access work without getting into DAO, but my memory may be
failing

me.

I hope that makes sense - thanks in advance for the help/patience.
 
D

david epsom dot com dot au

ADO is not 'native' to Access. It was originally created

set me.recordset = application.currentproject.execute "..."

set obj = Application.CurrentProject
set rs = obj.execute "select * from ...
set me.recordset = rs


Obviously, you can argue about what 'native'
'aboriginal', 'exotic' or 'naturalized' mean.
English has many words, but even in English
there is not a separate word for every separate
concept.

In this case, I mean that you can bind ADO objects to forms,
and use ADO objects in code, without referencing the registry
(CreateObject) or referencing a type library (New): they are
a native part of Access.

(david)


David C. Holley said:
ADO is not 'native' to Access. It was originally created as a means to
generically connect to a database.

david@epsomdotcomdotau said:
The menu commands that you see in Access are 'native', and
they are wrappers to Jet commands. Access may talk directly
to the Jet DLL's, but it mostly seems to be DAO.

Both ADO and DAO are 'native' to Access. You can get DAO
or ADO from the Application object:

(david)

I'm new to Access 2003...I'm confused about how to interact with Access
tables in Access VBA. When I am writing Access VBA code, do I need to use
ADO

(I know the ADO vs. DAO arguments) to interact with my database/tables?
Or
is

there a [better/easier?] "native Access" way to do this? I know I can
issue

SQL commands, but I've also seen a thread or two refer to "native Access"
commands. Simple forms seem avoid any ADO...is that just coded behind the
scenes by Access?

I don't mind using ADO if I have to, but I'm also looking for rapid
development and want to avoid the learning ADO if it isn't needed. I
worked

with Access 97 years ago, and I seem to recall being able to do some
pretty

detailed Access work without getting into DAO, but my memory may be
failing

me.

I hope that makes sense - thanks in advance for the help/patience.
 
D

David C. Holley

Using the code posted as an example of ADO being native to Access you
could argue that Outlook is 'native' to Access given that I can create
and manipulate Outlook items from within Access.

The prime difference between ADO and DAO, as it applies to this
discussion, is that Jet uses DAO itself. Since Jet is the engine behind
Access, it is appropriate to say that DAO is native to Access while ADO
is not native.
ADO is not 'native' to Access. It was originally created


set me.recordset = application.currentproject.execute "..."

set obj = Application.CurrentProject
set rs = obj.execute "select * from ...
set me.recordset = rs


Obviously, you can argue about what 'native'
'aboriginal', 'exotic' or 'naturalized' mean.
English has many words, but even in English
there is not a separate word for every separate
concept.

In this case, I mean that you can bind ADO objects to forms,
and use ADO objects in code, without referencing the registry
(CreateObject) or referencing a type library (New): they are
a native part of Access.

(david)


ADO is not 'native' to Access. It was originally created as a means to
generically connect to a database.

david@epsomdotcomdotau said:
The menu commands that you see in Access are 'native', and
they are wrappers to Jet commands. Access may talk directly
to the Jet DLL's, but it mostly seems to be DAO.

Both ADO and DAO are 'native' to Access. You can get DAO
or ADO from the Application object:

(david)



I'm new to Access 2003...I'm confused about how to interact with Access
tables in Access VBA. When I am writing Access VBA code, do I need to use

ADO


(I know the ADO vs. DAO arguments) to interact with my database/tables?
Or

is


there a [better/easier?] "native Access" way to do this? I know I can

issue


SQL commands, but I've also seen a thread or two refer to "native Access"
commands. Simple forms seem avoid any ADO...is that just coded behind the
scenes by Access?

I don't mind using ADO if I have to, but I'm also looking for rapid
development and want to avoid the learning ADO if it isn't needed. I

worked


with Access 97 years ago, and I seem to recall being able to do some

pretty


detailed Access work without getting into DAO, but my memory may be

failing


me.

I hope that makes sense - thanks in advance for the help/patience.
 
A

Albert D.Kallal

When you are dealing with a regular form, then you don't need to use ado, or
dao recordset to modify, or work with the forms data.

So, if you are trying to "remember" the other way, well...for the most part
your code can use the data on the particular form.

The only time you need to create a recordset is for processing code that
needs to operate on more then one record. And, further, *often* you can use
sql in place of that record set.

For example, lets say we need to change all City occurrences of "N.Y" to New
York. We could create a recordset, loop through each record as


dim rst as dao.RecordSet

set rst = currentdb.OpenReocrdSet("tblCustomers")

do while rst.Eof = false
if rst!City = "N.Y" then
rst.Edit
rst!City = "New York"
rst.Update
end if
rst.MoveNext
loop
rst.Close
set rst = nothing

On the other hand, could shorten the above code by using some sql to help
use. A sorter version could be:

dim rst as dao.RecordSet
dim strSql as string

strSql = "select * from tblCustomers where City = 'N.Y.' "

set rst = currentdb.OpenReocrdSet("strSql")

do while rst.Eof = false
rst.Edit
rst!City = "New York"
rst.Update
rst.MoveNext
loop
rst.Close
set rst = nothing

Of course, we could even eliminate he use of a recordset loop, and use
following PREFERRED code

strSql = "update tblCustomers set City = 'New York' where City = 'N.Y.'"
currentdb.Execute strSql,dbFailOnError

So, in those cases were you can use sql to do all the work for you, you
should, and you don't have to 'loop' through each record in many cases.
However, as the 2nd recordset loop shows, you can use a mix of sql to limit
the records, and still use looping code.
Simple forms seem avoid any ADO...is that just coded behind the
scenes by Access?

Well, actually, ms-access is rather smart. If you declare and use ado
reocrdsets, then ms-access will automatically "cast" the recordset from the
form
into ado for you (and, if you use dao...it returns dao so, the underlying
recordset is which ever you want!!). Note that all forms have their own
recordset, and even a recordset clone also. So, we don't actually have to
"open" and create a recordset, since a form has its own.

If we wanted to count the number of records attached to the current form, we
could put behind a button the following.

me.ReocrdSetClone.MoveLast
msgbox "current record count = " & me.RecordSetClone

Question:
is that built in recordset a dao, or ado recordset?
Answer, you often don't know!! If you are not going to use ado, then
remove the ref. However, if you are using both ado, and dao, then you often
need to disambiguate the above.

dim rst as dao.RecordSet

set rst = me.recordSetClone

Now, there is NO confusing here, as you defined the recordset. Note how we
did not have to open, or setup a connection, since the reocrdsetclone is
made for you when the form opens. Also note that you can use me.Recordset
(this feature is only available in a2000 and later).

me.RecordSetClone.MoveNext

me.ReocrdSet.MoveNext

In the 2nd movenext, the form will actually "jump", and "move" along as you
move the record pointer. However, with the ReocrdSetClone, the form does NOT
follow the recordsetclone pointer. And, don't confuse the above with
me.ReocrdSet . Clone (I put a space around the "." so you can see the
difference.

me.ReocrdSetClone (this is built into forms)
me.ReocrdSet (this is built into form, but only a2000 and
later)
me.ReocrdSet.Clone this is a methoed of the recordset to "clone"


set rst = me.RecordSet.Clone (if you move the rst pointer..the
form will jump).

So, for general processing routines, I tend to use the reocrdsetclone..as
you can do things with it...but not make the form flicker and jump around.

On the other hand, you might want the form to jump

me.RecordSet.FindFirst "City = 'Edmonton' "

The above would find the first city = Edmonton...and the form would jump

me.RecordSetClone.FindFirst "City = 'Edmonton'"
if me.ReocrdSetClone.NoMatch = false then
me.BookMark = me.ReocrdSetClone.BookMark
end if

Hum, never tried, but I suppose the above book mark code could be

me.RecordSet.BookMark = me.ReocrdSetClone.BookMark

I hope the above jogs the memory....
 
B

Brendan Reynolds

When you're writing code behind a bound form, Access exposes both the
controls on the form, and the fields in the current record of the form's
recordset, as properties of the form. So you can do things like Me.FieldName
= SomeValue without using either ADO or DAO. When you need to address data
not in the form's recordset, though, you're likely to need ADO or DAO. So in
short, yes, there are many things that you can do without ADO or DAO, but in
any non-trivial application you will need to use ADO or DAO, or both.
 
D

david epsom dot com dot au

To create an Outlook object in Access, you would have to look
either in the registry (using CreateObject or GetObject), or
in a type library (using New).

Using ADO in Access does not require that you look either
in the registry, or use a type library, because ADO is native
to Access.

Even after you created an Outlook object, using the registry
or a type library, you would not be able to bind it to an
Access form.

You are able to bind an ADO recordset to an Access Form,
because ADO is native to Access.

I provided an example of using the native Access connection
object to bind a native ADO recordset to a native Access Form.
Here it is again:

set me.recordset = application.currentproject.execute "..."

I am unable to bind an Outlook object to a Form. Can you
demonstrate?

<deleted>

DAO uses Jet, ADO uses Jet. Jet does not use DAO.
ADO uses ODBC, ADO uses ODBC. ODBC does not use DAO.
Access uses DAO. Access use ADO.


(david)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top