Bad Form Design

[Fairytale]

I had an autonumber error and have fixed that but the information I read
suggested I have a bad form design and that there is no reason to have
subforms that relate back to the same table. I am working from a database
that was built by my predecessor, this was how he had it set up. I do have a
lot of data fields and like that they can be organized in sections using the
subform system, however, I beleive I need to change this "bad design". How
can I make it simple to "skip to" the desired section of form fields without
using the subform?

 

[golfinray]

You need to know what kind of relationship you have. A one-to-one
relationship is where you have one product, salesman, something like one
fisherman, one kind of fish. One-to-many is like a one librarian, many books.
For one-to-one relationships you usually only need one table, one form, no
subforms. One-to-many you need two tables, one mainform, one subform. The
mainform is the one side and the subform is the many side. Establish what
kind of relationship your data has and then post back for more design info.

 

[Bill Mosca]

Fairytale

All you need to do is move the controls off of the sub form onto the main
form. If space is an issue you can always use a tab control to break things
up in a logical layout.

Once all the controls are off the sub form you can delete it.

 

[John W. Vinson]

I had an autonumber error and have fixed that but the information I read
suggested I have a bad form design and that there is no reason to have
subforms that relate back to the same table. I am working from a database
that was built by my predecessor, this was how he had it set up. I do have a
lot of data fields and like that they can be organized in sections using the
subform system, however, I beleive I need to change this "bad design". How
can I make it simple to "skip to" the desired section of form fields without
using the subform?

If you have so many fields displayed on your form that you need subforms to
manage them, it's quite possible that the fault is not so much in the form
design as in the table design. What's the structure of your table? How many
fields? If there are more than a dozen or so, what are some representative
fieldnames? Might you have a "wide flat" design embedding one to many
relationships within each record?