Max Recommended No of text boxes in a Form?

P

Pete

Been asked to make a Form with potentially 1000 text boxes. Feels a bit
steep! Is there a recommended maximum of Boxes in a Form such that it will
still function smoothly. Thanks
 
W

Wayne-I-M

Hi Pete

That doesn't sound right.

What would the form be used for

--
Wayne
Manchester, England.
Enjoy whatever it is you do
Scusate,ma il mio Inglese fa schiffo :)
Percio se non ci siamo capiti, mi mandate un
messagio e provero di spiegarmi meglio.
 
W

Wayne-I-M

Copied from the help field

FORM
Number of characters in a label 2,048
Number of characters in a text box 65,535
Form or report width 22 in. (55.87 cm)
Section height 22 in. (55.87 cm)
Height of all sections plus section headers (in Design view (Design view: A
window that shows the design of these database objects: tables, queries,
forms, reports, macros, and data access pages. In Design view, you can create
new database objects and modify the design of existing ones.)) 200 in. (508
cm)
Number of levels of nested forms or reports 7
Number of fields or expressions you can sort or group on in a report 10
Number of headers and footers in a report 1 report header/footer; 1 page
header/footer; 10 group headers/footers
Number of printed pages in a report 65,536
NUMBER OF CONTROLS AND SECTIONS YOU CAN ADD TO A FORM OR REPORT 754
Number of characters in an SQL statement that serves as the Recordsource or
Rowsource property of a form, report, or control (both .mdb and .adp) 32,750



--
Wayne
Manchester, England.
Enjoy whatever it is you do
Scusate,ma il mio Inglese fa schiffo :)
Percio se non ci siamo capiti, mi mandate un
messagio e provero di spiegarmi meglio.
 
T

tina

well, the point isn't really whether the form will function "smoothly" (how
do you define smoothly, btw?). you have more vital issues to consider.

first, and by far the most important, is: is your data table(s) normalized?
a thousand fields is HUGE, especially considering that most normalized
tables have a maximum of 25-30 fields, usually much less. even if the data
IS normalized, putting together enough tables in a query to get 1000 fields
for a form's RecordSource, and keeping the query updateable, sounds
impossible to me.

the second consideration is ease-of-use. even with tab pages to organize and
group controls logically, entering data in such a form would be a nightmare
for the user. and frankly, i can't imagine any data entry source
documentation that would require that many controls to enter all the data
for a single record - if the underlying data tables are properly normalized.

i strongly recommend that you stop now, read up on normalization principles,
and then re-examine your tables/relationships design - before you go any
further in building your database. see
http://home.att.net/~california.db/tips.html#aTip1 for more information.

hth
 
W

Wayne-I-M

Hi Tina

I agree with everything you say regard normaling the DB.

But I still really interest to know "what" was going to be on the form.
Sounds interesting. Maybe Pete will let us know.

--
Wayne
Manchester, England.
Enjoy whatever it is you do
Scusate,ma il mio Inglese fa schiffo :)
Percio se non ci siamo capiti, mi mandate un
messagio e provero di spiegarmi meglio.
 
T

tina

sounds scary to me <g>
i do data entry (among other duties) for a living; if my boss ever sat me
down to enter data in a form with a thousand "fields", i think i'd just save
myself the misery and quit on the spot. ;)
 
M

missinglinq via AccessMonster.com

I'm with Wayne-I-M, I want to know the purpose of this proposed mega-base!
MAkes me wonder if Access is the right tool for the project.
 
W

Wayne-I-M

I did make a form once for an evening adult class to show the way "not" to do
things.

I had a table called tblNumbers and a field for each number from 1 to 255.

I made a calculator form with each field on it and a OnClick event to
setvalue to a calculated field in the header. That was quite good fun
actually - I thought it looked quite good even if mad. But I don't think any
paying clients would be too happy <:)

--
Wayne
Manchester, England.
Enjoy whatever it is you do
Scusate,ma il mio Inglese fa schiffo :)
Percio se non ci siamo capiti, mi mandate un
messagio e provero di spiegarmi meglio.
 
T

Tom Lake

tina said:
well, the point isn't really whether the form will function "smoothly"
(how
do you define smoothly, btw?). you have more vital issues to consider.

first, and by far the most important, is: is your data table(s)
normalized?
a thousand fields is HUGE, especially considering that most normalized
tables have a maximum of 25-30 fields, usually much less. even if the data
IS normalized, putting together enough tables in a query to get 1000
fields
for a form's RecordSource, and keeping the query updateable, sounds
impossible to me.
Click to expand...

I once had to program a research survey with 800 questions. I ended up
making
several tables related in a one-to-one fashion. It worked well but it's not
something I'd want to do every day!

Tom Lake
 
J

John Vinson

T

tina

well, a survey database needs, among others, a table for questions, a table
for answer choices, and a table for responses. in a normalized database
structure, the number of fields in those tables will be the same whether
they deal with 8 questions, or 800, or 8000, and regardless of how many
respondents there are.

you can download an example of a tried-and-true survey solution from MVP
Duane Hookom, at
http://www.rogersaccesslibrary.com/OtherLibraries.asp#Hookom,Duane.

hth
 
P

Pete

Delighted at your response and those of your colleagues. Makes life much
easier for me. I have a list of 90 stock items in a wine shop where on a
daily basis the stock number is checked, deliveries are noted, sales are
noted and the value of the final stock is noted. There are then other things
related to different Credit Cards used for purchase and the amount to which
they all total.
 
J

John Vinson

Delighted at your response and those of your colleagues. Makes life much
easier for me. I have a list of 90 stock items in a wine shop where on a
daily basis the stock number is checked, deliveries are noted, sales are
noted and the value of the final stock is noted. There are then other things
related to different Credit Cards used for purchase and the amount to which
they all total.
Click to expand...

"Fields are expensive, records are cheap".

You would not have a separate FIELD for each stock item. You'ld have a
second table with one RECORD for each item, displayed on your form in
a Subform. You can do totals of the values in the subform. By having a
separate table, you don't need to redesign all your tables, queries,
forms etc. when you add or remove a new stock item.

I'd suggest that you look at the Northwind sample database and read up
on "normalization", starting with the Database Design 101 links on the
first of these websites:

Jeff Conrad's resources page:
http://home.bendbroadband.com/conradsystems/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

John W. Vinson[MVP]
 
Top