datasheets

[Don]

I'm new to Access and am very happy and satisfied to find
this users group. Someone out there please edumacate me.
From reading various posts here it seems that using
datasheets for data entry is a NO NO. Why is that?

Thanks for everyones contributions!

 

[Ken Snell]

By datasheets, I assume you mean entering data directly into a table.

The reason this is not recommended is because tables have no error handling,
very minimal data validation, cannot create children records, etc. Plus,
never ever ever let a user see and interact directly with your data in the
table. Forms give you the ability to control what the user sees and what the
user does.

 

[Bill Nicholson]

My feeling is that a datasheet is a quick-and-dirty way to get data into a
table but it's not a good user interface. You can't implement the kind of
data validation necessary to protect a user from himself. There's no events
taking place and therefore no code behind a datasheet. I've written many
commercial apps for a wide range of customers and I've never exposed a
datasheet to a user.

I usually find that a 'record' deserves more than a row's worth of space on
a form anyway. I almost always end up dedicating an entire form to each
individual record such that the user has to page up and down between records
instead of viewing multiple records on the form at the same time. I also
provide a combo box to further assist in record navigation.

Just my thoughts!

Bill
Cincinnati, OH USA

 

[Guest]

Thanks for the info.
We have one client that wants as Bill (thanks for your
advice!) put it the ability of "viewing multiple records
on the form at the same time". This aids them in
determining the input for other records. They have 3 main
tables with which to work. The first is a grouping of
input data gathered from the public. Based on that table
they will group like topics into the second table with
their response. The third is used to create "issues" from
the second.

My first approach was with forms as described by Bill.
They didn't like that - too many forms to go back and
forth. I tried tabs with forms and subforms - same
reaction. The latest attempt was 3 datasheets (so they
could see multiple records) as subforms on one form which
they really liked. Is there a better approach (especially
now that they now want a child table (one-many) for the
second main table)?

Again, THANKS in advance for your help!

 

[Guest]

Thank you Ken for your reply.
Would you have a minute to reply to my reply to Bills
reply?

THANKS a bunch in advance!

 

[Bill Nicholson]

I'd still resist the datasheet solution and present them with 3 forms that
are in synch with each other. Or the same form object cloned 3 times and
presenting 3 different records from the same dataset. You can open all 3
forms programatically and arrange them on the screen such that they are all
visible and any record navigation in any of the 3 forms will cause all 3
forms to load a new record.

Don't you love customers? This business would be so much more fun
without them.


Bill
Cincinnati, OH USA

 

[Steve Schapel]

Don,

I may be wrong here, but I suspect that both Bill and Ken have
interpreted your word "datasheet" to mean accessing the tables directly,
whereas your solution seems to refer to using a subform in datasheet
view, which is another matter entirely. A datasheet subform can work
fine. I would point out, though, that a continuous view subform can do
most of what a datasheet subform can do (with the exception of
subdatasheets). But there are also many advantages to the continuous
view subform over the datasheet subform, amongst them the ability to use
controls like option groups, command buttons, etc.