Access Forms?

Can anyone recommend a good book on developing efficient
access forms that can perform calculations and save such
calculations in the underlying table/s

Thanks
Xavier

"Xavier" wrote in message
...
Can anyone recommend a good book on developing efficient
access forms that can perform calculations and save such
calculations in the underlying table/s

Since saving calculations into tables is generally regarded as a bad idea
and a violation of proper database design I doubt that you will find a book
describing how to do it.

On those *rare* occasions where it is necessary you generally need to have
code run in the form that does the calculation and then "stuffs" the result
into a bound TextBox on the form where it will be saved to the table just
as any other bound control would be.


--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

On Tue, 22 Jun 2004 13:51:08 -0700, "Xavier"
wrote:

Can anyone recommend a good book on developing efficient
access forms that can perform calculations and save such
calculations in the underlying table/s

No such book exists, because no professional designer would do such a
thing except in very rare circumstances.

Storing derived data such as this in your table accomplishes
three things: it wastes disk space; it wastes time (almost
any calculation will be MUCH faster than a disk fetch); and
most importantly, it risks data corruption. If one of the
underlying fields is subsequently edited, you will have data
in your table WHICH IS WRONG, and no automatic way to detect
that fact.

Just redo the calculation whenever you need it, either as a
calculated field in a Query or just as you're now doing it -
in the control source of a Form or a Report textbox.

Could you explain the *real life problem* that you are trying to
solve? It's surely soluble - but storing calculations in the table is
not likely to be the best way to solve it!

John W. Vinson[MVP]
Come for live chats every Tuesday and Thursday
http://go.compuserve.com/msdevapps?loc=us&access=public

Real world scenario, which after thinking about what you
said you do have a point.

I gather data which is kinda like a survey based on a
series of 30 questions and your score is based on how
many of the questions are applicable to you specificaly.
My thought in saving the final calculation of the score
is I can Archive just one table for future reference
instead of the whole database, currently I have one
archive database which has one table with final results
for each year this process has run.

After I placed the msg yesterday I just fiddled with my
form and got it to do exactly what I wanted but I would
still like to find a good book to help me make better and
more efficiant forms.

I have self tought what I know about access since access 2
and now in 2002.

What im really interested in is better forms and better
use of controls to represent and manipulate my data,
usualy each year I handle about +-300k to 500k records
which when I finish I archive and start with a fresh set
of records.

any sugestions on books for reference is appreciated.
Xavier

-----Original Message-----
On Tue, 22 Jun 2004 13:51:08 -0700, "Xavier"
wrote:

Can anyone recommend a good book on developing
efficient
access forms that can perform calculations and save
such
calculations in the underlying table/s

No such book exists, because no professional designer
would do such a
thing except in very rare circumstances.

Storing derived data such as this in your table
accomplishes
three things: it wastes disk space; it wastes time
(almost
any calculation will be MUCH faster than a disk fetch);
and
most importantly, it risks data corruption. If one of
the
underlying fields is subsequently edited, you will have
data
in your table WHICH IS WRONG, and no automatic way to
detect
that fact.

Just redo the calculation whenever you need it, either
as a
calculated field in a Query or just as you're now doing
it -
in the control source of a Form or a Report textbox.

Could you explain the *real life problem* that you are
trying to
solve? It's surely soluble - but storing calculations in
the table is
not likely to be the best way to solve it!

John W. Vinson[MVP]
Come for live chats every Tuesday and Thursday
http://go.compuserve.com/msdevapps?loc=us&access=public
.