Can I Use Tabs in This Scenario?

[skyrise via AccessMonster.com]

Thanks in advance for your input.

I have all of my control fields in one Main Table.
All of my subforms are in a Primary-key/Foreign-key relationship with the
main table.
There are too many control fields and subforms to fit on one Form grid.
Therefore, I need to split things out over multiple pages.
I’m thinking of trying to use tabs as a simple solution, but need some
clarification on how to use them.

I open up a blank form in design view and add a Tab control. I can basically
size the tab control to fit the full size of the form (in my case to fit
within an 8 x 11.5 inch printable page).

Can I place ALL of my control fields and subforms directly onto the various
tab pages (maximize the size to 8 x 11.5) or do need to leave space on the
grid because some of the controls have to go onto the grid itself (such as
the Autonumber Record ID field)?

Becasue everything is linked back to one Main Table, the data that will be
typed into on each tab by the users will automatically be associated with one
record (based on the Autonumber Record ID)?

Do I need to repeat the Autonumber Record ID field on each tab or need to
have any written programming behind any Event Procedures to tie everthing
together?

 

[Beetle]

There are too many control fields and subforms to fit on one Form grid.

This statement may or may not be cause for concern depending upon
what you mean by "too many fields". If any one of your tables has more
than, say, 20 - 30 fields, then it is probably incorrectly designed. If that
is the case, than that issue should be addressed before you get too
involved with form design.

I open up a blank form in design view and add a Tab control. I can basically
size the tab control to fit the full size of the form (in my case to fit
within an 8 x 11.5 inch printable page).

This implies that you are designing your form on the basis of how you want
it to look when it's printed, which is a mistake. Forms are not intended to
be printed, that is what reports are for. Forms are intended to provide a
user friendly way to manage data entry and display.

Can I place ALL of my control fields and subforms directly onto the various
tab pages (maximize the size to 8 x 11.5) or do need to leave space on the
grid because some of the controls have to go onto the grid itself (such as
the Autonumber Record ID field)?

Autonumber fields serve the purpose of providing a way for the application
itself to uniquely identify each record and have no useful meaning to
the users, so in most cases you would not display this on your form at all.
It is not necessary for *every* field in your form's record source to have
an associated control on the form. As long as the field exists in the record
source, it can be easily referenced by the form (or it's subforms), whether
it has an associated form control or not.

Do I need to repeat the Autonumber Record ID field on each tab or need to
have any written programming behind any Event Procedures to tie everthing
together?

No. As I stated before, the ID field does not need to appear on your form
at all, it just needs to exist in the record source (the table/query that the
form is based on).

The connection between a main form and it's embedded sub forms is
handled by the Link Master Fields / Link Child Fields properties of the
subform control. The fact that the subforms may exist on different tabs
has no bearing on the behavior of the Master/Child link.

 

[skyrise via AccessMonster.com]

The database build project is to take a survey form and allow users to input
the multiple choice answers, select all that apply answers, % of population
calculation tables, etc. into a database.

I have approximately 30 fields and 15 subforms. I wish I could upload a copy,
but this fourm doesn't seem to allow that.

My initial design was to split the 30 fields and related subforms out on 3
forms. However, with my low level of Access knowledge, I didn't know how to
associate the 3 different forms as relating to one record. There seemed to
be SQL/VBA script that needed to be written to tell the program to link
fields and carry over information. I unfortunately don't have project time
to learn that much. I came across informaton about Synchronized Forms and
the Synchronized Form Wizard, but don't know if that's a solution.

So, my second attempt was to put the direct data entry fields (30) into one
table, relate the subforms to the primary key in the Main Table, and put it
all on one form. This is where I ran into the Veritical form size space
issue. I could make the form wider, but that's not really practical from the
perspective of scolling and the page jumping around during data entry.
That's why I was trying to use an 8 inch wide build guide. The office here
has old CRT's with old resolution, so everything appears on the screen more
"zoomed in" than they would appear on a modern flat-screen LCD.

I'm trying to figure out the best compromise and approach. The forms
themselves won't be printed out. The data is going to be exported into Excel
spreadsheets for data analysis.

 

[Beetle]

I don't personally have any experience designing a survey database,
but I can tell you that Access MVP Duane Hookom has an example
Access application called "At Your Survey". I can't post the link right now
but if you do a google search you should be able to find it. It is freely
available to download.

It seems to be widely regarded as a very good example application. If
you don't have much time for this project then maybe you will find his
application suitable for your needs.

 

[John W. Vinson]

I don't personally have any experience designing a survey database,
but I can tell you that Access MVP Duane Hookom has an example
Access application called "At Your Survey". I can't post the link right now
but if you do a google search you should be able to find it. It is freely
available to download.

Duane Hookum's "At Your Survey":
http://www.rogersaccesslibrary.com/Otherdownload.asp?SampleName='At Your Survey 2000'