HK said:
I'm looking for a good site on DAO for newbies. Anyone have any
recommendations?
You don't mention what version of ms-access you are using, but in a2003,
while in the code editor (you *must* be in the code editor), simply go
Help-> Microsoft Visual Basic Help
On the right side, you will see a "table of contents", and the 3 one is a
full DAO reference
The 2nd entry is ADO.
Also, I haven't seen any with
information on why we need to declare our database etc.
"why" we do this is rather a general question. Why do we build combo boxes
on a form?
For the most part, I never do declare the database object, and use current
db.
So
dim rstCustomers as dao.recordset
set rstCustomers = currentdb.OpenReocrdSet("select * from tblCustomers where
city = 'N.Y.'")
In the above, it is only two lines of code...and I did not need to, nor care
to declare a database object.
So, you actually don't have to declare a database object, and most of the
time I don't. As you can see,
2 lines code can suffice. And, I could even not declare the reocorset if I
don't want to!!
strCompanyName = currentdb.OpenReocrdSet("select * from tblCustomers where
city = 'N.Y.'")(0)!CompanyName
So, the above one line opens a reocrdsset, and sets the string value of
company to our string var.
So, the "why" we declare a database object is mostly a preference thing on
your part to make using the database
object somewhat easier to work with. However, you don't HAVE to declare the
object, and for the most
part I use currentdb...
For the
longest time I didn't understand that my Access forms are accessing my
data using DAO, even though I never declared anything.
Actually, the above is not always the case. In fact, ms-access is quite
smart,
and if you base a form on a ado reocrdset, then ado is used. If you base a
form on a dao reocordset, then dao is used And, if you use an existing form,
the type of reocreset returned by the form is going to depend on how you
declare your variables.
However, for the most part, you are correct.
I have various
questions like, can I declare my db once at the opening and never have
to set my db variable again?
Sure, you can do the above. You would have to declare a global variable in a
standard code module. Then you are startup code could go
set db = currentdb
However, we all know that developers around the world VERY MUCH will
discourage you to use a global var when you don't need to. Further, what
about importing forms or grabbing code examples from other applications you
built? Perhaps you did not declare that global var, and thus existing code
can't be easily adopted from one application to another. Remember, the
largest cost of development is maintains existing code, and also being able
to re-use code inn other applications. So, the goal making more modular code
is a greater goal then eliminate you having to declare the db object each
time. And, in fact as I mentioned, I never declare it anyway...I use the
built in method called CurrentDb.
Note that if that other code examples and even previous code that you wrote
does not assume a global var called db, the you will have to modify that
code. Further, if you have a un-handled code error, then all global vars are
re-set, and thus you would loose your global db var anyway. So, the benefit
of you predefined a global var are not much, and importing forms code, and
other examples into your existing application will thus have to be modified
to use this global db of yours. There is just not much of a benefit here at
all to use a global db var. However, you *can* use one if you wish....
As mentieond, the key to good software development is to write modular stand
alone code, and that is easer to copy/re-use, debug, and less effort to
maintain in the long run...
When I reset my recordsource for my form
through code, should I use specific DAO methods to do this? I normally
don't.
You don't have to. However, if you have a ADO reference, or use ado code in
your application, then often you should specifically force and declare the
reocrdset type.
So, in place of
me.ReocrdSetClone.FindFirst "id = 1233"
You might conisder suing
dim rstMyClone as dao.RecordSet
set rstMyClone = me.RecordSetClone
rstMyClone.FindFirst "id = 2323"
In the above, since you "force" the type of reocrdset, then there can be no
confusing.
Since I don't use ado at all, then I do NOT HAVE a ado reference set, and
thus I don't have to really worry about this problem...
However, as a habit...I do prefix my dao objects with dao now..
eg
in place of
dim rst as reocrdset
I use
dim rst as dao.recordset
