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

It depends.

If it's a very simple personal database for your own use, then it may be
perfectly OK to edit data directly in tables. If you're developing for other
people, though, you'll definitely want to use forms. Tables don't fire any
events that you can hook code into, so if you want to be able to use code to
react to user actions, you need to use forms.

The list of things that you can do with forms that you can't do with tables
is really limited only by your experience and imagination. You can display
data from multiple tables, present the user with appropriate choices,
validate data and display feedback and guidance, to list just a few of the
many possibilities.

Data*** forms are OK if used sensibly. For example, you don't want to bind
a form directly to a table containing tens of thousands of records in a
multi-user application, not unless you want to make a mortal enemy of the
network administrator. But you might use an unbound form to allow the user
to make some choices which you then use as criteria to select a subset of
records to be displayed in a data*** view.

--
Brendan Reynolds (MVP)


"Tim Fierro" <partsmanager@xxxxxxxxxxxxx> wrote in message
news:s6KdnXQjz7q4U0vfRVn-oQ@xxxxxxxxxxxxxx
> 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?
>
>
> Tim
>
>
>
>
>


.