Forms should, in most cases, be based on queries, even if only a single table
is involved. Besides the ease of sorting, which can include multi-field sorts,
and the ability to retrieve subsets of data, such as active records only, you
have the advantage of being able to use calculated fields in queries.

One simple example would be in the handling of names. Best practice dictates
entering LastName and FirstName in separate fields, but there's many
situations where you'd want to the name to appear as a single unit. You could
do this at the form/report level *every single time* you need it to happen,
using

Me. CompleteName = FirstName & " " & LastName

or you could *do it once* in your query, using

CompleteName: FirstName & " " & LastName

in which case you simple refer to the calculated field

CompleteName

everytime you need it in that format.

Another example, using names again, would be if you wanted to use a combobox
to retrieve a person's data based on their name. Using the combobx wizard
takes less than a minute, but if your combobox, for example, includes the
fields

LastName
FirstName
Address
City
State
Zip

with the combobox being bound to the LastName, you'll run into problems if
you have more than one person with the same LastName. With this setup, if you
have persons named

Adams Aaron
Adams Benjamin
Adams Charles
Adams Dale

Access will always retrieve the data for

Adams Aaron

even if you select

Adams Dale

because Access is looking for the *first occurrence* of the bound field, in
this case Adams.

But if you once again have a calculated field in a query

RetrievalName: LastName & " " & FirstName

and bind your combobox to the calculated field RetrievalName, it will
retrieval data for the field you selected.

And there are many other, everyday applications for this type of data
manipulation.

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...forms/200804/1