limitations of controls on forms

C

Cindy

I have a log form that I am trying to produce. This form has 31 days with 35
categories that I am trying to produce with the amount of time each day in
each category all on one form (or one sheet of paper). This is a form I
manually have to complete now and was wondering if anyone knows a what to
have more than 754 controls on a form. Will a subform help?
 
J

John Vinson

I have a log form that I am trying to produce. This form has 31 days with 35
categories that I am trying to produce with the amount of time each day in
each category all on one form (or one sheet of paper). This is a form I
manually have to complete now and was wondering if anyone knows a what to
have more than 754 controls on a form. Will a subform help?
Click to expand...

STOP. Right now. <g>

Designing a Form to fit an existing paper form is pretty sure to give
you a BADLY DESIGNED form.

Designing Tables to fit an existing formis almost *certain* to give
you badly normalized tables.

You should design your tables FIRST: in this case, I'd see three
tables with very few fields each. I don't know what you're "logging"
but I'd see a table for whatever event or entity is being logged; a
second table (with 35 rows, at least at the moment) for categories;
and a Log table with fields for the EntityID, the CategoryID, and the
date (the whole date, not just the day of the month - otherwise how
can you tell if it's the August 20 log entry or the September 20 log
entry?)

Basically if you're using a relational database, you should *start*
with a logically normalized table structure; design forms to use that
datastructure; and adjust the forms to be user-friendly. This may be a
bit of work but you'll be much better off in the long run.

John W. Vinson[MVP]
 
Top