SubForm & Main Form Based on Same Table

[Janna]

Is there anything "illegal" or undesirable about inserting a subform on a tab
control where the main form that holds the tab control and the subform are
both based on the same table?

 

[Maurice]

No there's nothing illegal about it. The question is probably if it makes
sense but you have to be the judge of that. If that's logical to you and
provides you with the functionality you are looking for why not?

hth

 

[John W. Vinson]

Is there anything "illegal" or undesirable about inserting a subform on a tab
control where the main form that holds the tab control and the subform are
both based on the same table?

Just that you can and will get "the record you are trying to edit has been
locked by another user" errors if you try to edit the same record in both
forms.

 

[tina]

well, in general i'd say updating the same record bound to two open forms at
the same time may not perform well consistently. but i'm more interested in
*why* you want to do this? if you'll explain what you're trying to
accomplish, maybe we can offer a suggestion that will be more dependable.

hth

 

[Janna]

I was asked to develop a “simple†database for a department where I work.
Initially it appeared one primary flat table for tracking the data they
needed would suffice (with several lookup tables). However, as we got more
into the process, the department continued to add fields, then remove fields,
then add the fields they wanted removed, back again. I had designed a main
data entry form with tab controls pointing to the initial flat table. It
worked well until I’ve run out of real estate on the form. I suppose I’m
being lazy and should really break up the primary flat table into multiple
tables to normalize the database and then use subforms based on the
appropriate tables. Since we don’t charge the department for the
development—it’s one of those “just work on it when you have spare timeâ€
project, they have no concept of the time involved developing forms/reports
and then editing them when massive changes occur. Sorry for venting. Just
getting a little frustrated.

 

[Rick Brandt]

I was asked to develop a "simple" database for a department where I
work. Initially it appeared one primary flat table for tracking the
data they needed would suffice (with several lookup tables).
However, as we got more into the process, the department continued to
add fields, then remove fields, then add the fields they wanted
removed, back again. I had designed a main data entry form with tab
controls pointing to the initial flat table. It worked well until
I've run out of real estate on the form.

How exactly have you run out of real estate if you are using a tab control?
Just add more pages, right?

I suppose I'm being lazy
and should really break up the primary flat table into multiple
tables to normalize the database and then use subforms based on the
appropriate tables.

Probably would be best.

Since we don't charge the department for the
development-it's one of those "just work on it when you have spare
time" project, they have no concept of the time involved developing
forms/reports and then editing them when massive changes occur.
Sorry for venting. Just getting a little frustrated.

Been there.

 

[tina]

yes, i can understand your frustration. you might stem the tide of changes
by initiating a process analysis, Janna. conducting a process analysis not
only gives the developer the information s/he needs to build a sound
structure with an interface that supports the users' workflow needs, it also
forces the user(s) - and/or their bosses - to define their own process (a
first, in more instances than you would believe) and clarify to themselves,
as well as to you, just what they need and expect from the finished
database.

hth