Multiple Subdatasheets

  • Thread starter Thread starter beekman001
  • Start date Start date
B

beekman001

Is there any way to make Access use / Display multiple sub-datasheet
when in table-view? I have a Table which has multiple sub-records i
other tables. I would like to be able to use subdata sheets for dat
entry, but i dont want users to have to manually switch which one i
currently on
 
data entry should not be done directly in tables except as needed during db
development, certainly never by end users. data entry should be done in
forms, where you can use a main form with multiple subforms to present a
parent table with multiple child tables.

btw, recommend you open each table in design view, open the Properties box,
and set the Subdatasheet Name property to [None].

hth
 
I could not agree with you more, but the users wont stand for it
tinawrote
Click to expand...
data entry should not be done directly in tables except as neede
during d
development, certainly never by end users. data entry should be don i
forms, where you can use a main form with multiple subforms t present
parent table with multiple child tables

btw, recommend you open each table in design view, open th Properties box
and set the Subdatasheet Name property to [None]

ht


"beekman001" <[email protected] wrote i
message Is there any way to make Access use / Display multipl sub-datasheet
when in table-view? I have a Table which has multiple sub-record i
other tables. I would like to be able to use subdata sheets fo dat
entry, but i dont want users to have to manually switch which on i
currently on
[/quote:7e59250654
Click to expand...
 
Well, to answer your initial question, the answer is NO. You can only have
one subdatasheet in the table view.
I could not agree with you more, but the users wont stand for it.
Click to expand...

And when the data in your database turns out to be wrong are those same
users going to accept the blame for it or will they push that over to you?
You have very little control over what they enter into tables if you allow
them to work directly in the tables. For the sake of your data and your
sanity, do NOT allow them to do that.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html
 
Lynn is absolutely correct. as the db developer, it's your responsibility to
safeguard the accuracy and integrity of the data, to the very best of your
ability. while satisfying your customers' preferences is important,
sometimes it's not in their best interests - and telling a customer that is
an unpleasant task that every developer faces from time to time. a developer
of integrity will refuse to design a database element that unnecessarily
jeopardizes his/her employer's business interests. (not least of all because
the developer will inevitably get blamed for it in the end.)

i have run up against this "table data entry or die" mindset before. my
experience has been that the end user adopts that mindset when he/she has
been forced to use a database that was poorly developed and/or not modified
after development to support changing business needs. there is nothing more
frustrating than trying to work in a user interface that just doesn't work
right - or maybe not at all. in desperation, the user resorts to entering
data directly into the tables just to get the job done on an ongoing basis,
and the bad experience leaves a deep scar. that resistance *can* be
overcome, if you make a point of developing a user interface that fully
supports the user's task, and flows like silk - and it really helps if you
can add a extra bell/whistle or two that gives them some advantage they've
never had before in doing the work.

and it helps to change your own expectation, as well. it's been my
experience that most people hate change, period. (i'm one of those people,
come to think of it. <g>) maybe 10-30 percent of users will love a new db
once they've seen how it can ease their workload, about 50-60 percent will
accept it but not be thrilled about it, and the last 20-30 percent will
never like it, period, just because it's new. i've learned to simply expect
those reactions and take them in stride; and i make a point of educating the
"boss(es)" on what to expect, as well - managing *their* expectations so
they don't perceive the project as a failure (this last point is important
to your job security <g>).

good luck.

hth
 
Back
Top