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

  • Thread starter Thread starter Tim Fierro
  • Start date Start date
T

Tim Fierro

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 Datasheet 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 Datasheet View, is this ok and if data
is changed will all related records be updated too?


Tim
 
Tim said:
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 Datasheet 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 Datasheet View,
is this ok and if data is changed will all related records be updated
too?
Click to expand...

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.
 
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.

Datasheet 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 datasheet view.
 
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'?
Click to expand...


Thank you Rick and Brendan for the answers. I appreciate learning a bit
more all the time.

Tim
 
Back
Top