dcount, dsum, dlookup question (not syntax)

[kaosyeti]

so i'm new to access but i've done a lot in the last 3 months since i looked
at it for the first time back then. so when i finished my first db for my
job, i cut it close to the end of the year trying to get it done in time for
january. now that i can take my time and add new reports to the existing db,
i'm left with a couple of general questions.

i got reasonably comfortable with dcount, dsum and dlookup so i used them
towards the end almost entirely. i'm pulling data directly from the tables,
w/o queries. is this a bad thing? i mean, is there anything wrong with just
using dcount and dsum to do all the calculations that i need? is it going to
harm my db in any way down the line?

secondly, and a little off the topic, what is the best way to integrate new
reports/forms that i create from today forward, for people who have the
existing version as it sits right now? how do i 'export' the report/form to
an email-able file so they can just insert it into their db?

thanks.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200512/1

[Steve]

I believe I read an article a few years back indicating that the domain
aggregate functions (i.e. DSum, DLookup, DCount, etc) have very high
overhead when compared to a procedure using queries to perform the same
tasks. I've always been taught that calculations should always be done
inside the query if you can't store them in a table, and that
summations and counting should be done through Sum() and Count() inside
your form or report. My two cents only, not necessarily good advice.
There are others here with much more experience with Access who might
chime in.

As far as updates/patches, what my company usually does is send out a
new .mdb file and call it a patch. The new .mdb contains any objects
that have been updated or changed. The user navigates to a section of
the existing program and selects the file path to the new .mdb file.
Then our code imports all the objects in the 'patch' database,
replacing the originals with those in the 'patch' and updating a
revision table. Even modules can be updated with this technique, which
makes it pretty versatile. You have to make sure you have code in the
original program to do the import before you give it to your users,
though.

Personally, I'd like to hear what others are doing to take care of
patches, updates, and upgrades.