Re: Always use a form; I think I get it...

Tim Fierro wrote:
> Hello,
>
> I have been reading these newsgroups over the past few months while
> writing a database here, and a constant message being stated is:
> Always Use A Form.
>
> Can I have a breakdown on these 3 choices of 'data editing'?
>
> 1) Direct Table Edit
> Supposedly the No-No. Always supposed to use a form to add/edit
> data. I don't however really remember seeing why you don't want to
> edit right in the table.
>
>
> 2) Form Edit
> This is the way we are supposed to (should) work with data in our
> database. Makes sense to control the data flow using a form so I can
> see that. It also makes the end user review what is happening on the
> screen in the form instead of making a slight tweak directly in a
> table where a mistake can happen. But surely there is more to this
> on why using the Form is the way to go.
>
>
> 3) Form (But in Data*** View)
> Ok, is this still considered a FORM and is it ok to edit data here,
> or is this bringing the table editing back and shouldn't be done?
> IOW, if someone is using a FORM but uses that form in Data*** View,
> is this ok and if data is changed will all related records be updated
> too?

When you see that advice the assumption is that the app in question is a
"real" application being used to accomplish a *business* task. If it's your
CD collection then use a table all you like.

The biggest thing is that forms have events so you can impose more rules and
business logic as data is entered that is simply not possible when entering
data directly into the table. Forms also allow you to see additional data
from related tables, see one thing while storing another, and just generally
allow you to produce a more structured view of the data.

Another very big thing in a network environment is that forms allow you to
load a single record at a time meaning that a single record is all that is
pulled over the network. Opening a table directly causes a lot of
unnecessary network traffic. Of course using a form does not guarantee
network efficiency, but it at least makes it possible.


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



.

Loading