473,320 Members | 1,804 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Is there a workaround for "too many fields defined"

I have a tabbed form that contains 12 different "pages" and when I try
and run the form I get the error message too many fields defined ---
which I believe is the 255 field limit in the record source.

I was wondering, that if I were to break the pages down to include
subforms... is the number of fields contained in the subforms added to
the field limit for the main form ???

Is there some other way to work around this error message ???

I am putting the pages of forms on a tabbed control to keep the form
syncronized during the add and edit phases.

Dec 6 '06 #1
12 18112
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

One dead giveaway is if you have any repeating fields - sequences such as:
Week1, Week2, ...
Employee1, Employee2, ...
Monday, Tuesday, ...
FirstQuarter, SecondQuarter, ...
Item1, Item2, ...
Whenever you see this kind of thing, it always means you need to create a
related table with lots of records instead of having lots of fields in your
table.

The table analyzer in Access may be able to give you some suggestions:
Tools | Analyze | Table

To learn more about this, search on "normalization." Here's some links:
http://home.bendbroadband.com/conrad...abaseDesign101

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"M G Henry" <mr*************@hotmail.comwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...
>I have a tabbed form that contains 12 different "pages" and when I try
and run the form I get the error message too many fields defined ---
which I believe is the 255 field limit in the record source.

I was wondering, that if I were to break the pages down to include
subforms... is the number of fields contained in the subforms added to
the field limit for the main form ???

Is there some other way to work around this error message ???

I am putting the pages of forms on a tabbed control to keep the form
syncronized during the add and edit phases.

Dec 7 '06 #2
Surely the wait with a form of this magnitude would drive you bananas!
To answer your question, nesting subforms will seemingly give you
endless amounts of controls to have present but the control limit is
there for performance reasons, it's best not to try to circumvent it.

It would make more sense to logically separate your data better, you
can't forget that Access Forms and a windowed application are non
completely interchangeable. A form is made to present one set of data
in a meaningful way...the more you pile in, the less meaningful it
becomes.

You may be in an industry where you deal with an enormous variety of
variables (such as I do) and if this is the case normalisation is not
always the answer. For presentation purposes, logical separation of the
data is appropriate.

If you can give more specifics of your case I could probably point you
in a more specific direction.

Good luck!
-Mal W

M G Henry wrote:
I have a tabbed form that contains 12 different "pages" and when I try
and run the form I get the error message too many fields defined ---
which I believe is the 255 field limit in the record source.

I was wondering, that if I were to break the pages down to include
subforms... is the number of fields contained in the subforms added to
the field limit for the main form ???

Is there some other way to work around this error message ???

I am putting the pages of forms on a tabbed control to keep the form
syncronized during the add and edit phases.
Dec 7 '06 #3
Allen Browne wrote:
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.
The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ). I have used some subforms in my design and so I now will
break down the more complicated forms into more subforms to get my
total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.

Dec 7 '06 #4
Allen Browne wrote:
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ). I have used some subforms in my design and so I now will
break down the more complicated forms into more subforms to get my
total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.

Dec 7 '06 #5

Allen Browne wrote:
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ). I have used some subforms in my design and so I now will
break down the more complicated forms into more subforms to get my
total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.

Dec 7 '06 #6
Allen Browne wrote:
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ). I have used some subforms in my design and so I now will
break down the more complicated forms into more subforms to get my
total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.

Dec 7 '06 #7
Allen Browne wrote:
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ). I have used some subforms in my design and so I now will
break down the more complicated forms into more subforms to get my
total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.

Dec 7 '06 #8
"M G Henry" <mr*************@hotmail.comwrote in message
news:11**********************@73g2000cwn.googlegro ups.com...
Allen Browne wrote:
>You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ).
Access queries cannot have more than 255 fields. If you created such a query
then it is the query that is giving you the error, not the form.

Taking all of your properly designed and normalized tables and combining them
into one giant query is NOT the proper way to go about things. You need to use
a combination of forms, some with subforms, and some that are opened separately
as popups to show related data.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Dec 7 '06 #9
"M G Henry" <mr*************@hotmail.comwrote in
news:11**********************@73g2000cwn.googlegro ups.com:
Allen Browne wrote:
>You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form,
and can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you
have hundreds, there's a very high chance that you are designing
something that looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 (
not by much ). I have used some subforms in my design and so I now
will break down the more complicated forms into more subforms to get
my total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.
Databases are, of necessity, vertical. The problem you describe is
typical of a horizontal orientation (although your particular problem
itself may not be.) I could not deal conceptually with 250 fields
concurrently; I expect something less than twenty-five is my limit. So I
have difficulty imagining this form, comprised of subforms and tabs, and
its being necessary or useful. Nor have I ever seen such a form, after
almost twenty-five years as a Database Developer, either of my own
creation or that of another experienced Developer.
Simple, clean, efficient designs are almost always best.
This may give you cause to reconsider your design. On the other hand you
may be sure you are right and that this is the only or best way. If you
succeed in solving the 250 field problem what will you have? My guess is
that you will have a very slow and nasty animal which will bite you as
creator, and all its users every day until it is euthanized.

--
Lyle Fairfield

http://www.ffdba.com/toyota/BurlingtonToyotaLease.htm

(just a sad story - read if bored)
Dec 7 '06 #10
"Rick Brandt" <ri*********@hotmail.comwrote in
news:ZS*******************@newssvr14.news.prodigy. net:
Taking all of your properly designed and normalized tables and
combining them into one giant query is NOT the proper way to go
about things. You need to use a combination of forms, some with
subforms, and some that are opened separately as popups to show
related data.
Or use the OnChange event of the Tab control to change the
recordsource of the main form so that the controls on the particular
tab can be populated from the subset of all the fields needed for
it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Dec 7 '06 #11
Allen Browne wrote:
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ). I have used some subforms in my design and so I now will
break down the more complicated forms into more subforms to get my
total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.

Dec 8 '06 #12

Allen Browne wrote:
You can have up to 255 fields in a table or query, and up to 700-odd
controls on a form. A subform counts as one control on the main form, and
can have its own controls and RecordSource (so fields.)

However, a well designed table rarely has more than 50 fields. If you have
hundreds, there's a very high chance that you are designing something that
looks like a spreadsheet, i.e. it is not relational.

The structure that I am using has the individual pages based upon
tables that have sometimes as few as 10 to 15 fields, but no more than
60 or so fields...

The problem I am running into is that the record source for the tabbed
control has to have me declare the field names for all the tables
linked to all the pages, so my total number of fields exceeds 255 ( not
by much ). I have used some subforms in my design and so I now will
break down the more complicated forms into more subforms to get my
total number of fields on the record source below the 255 limit.

I can only imagine that the layering of the subforms inside of the
forms, would create performance issues, however, this application will
be used by a small number of users and I hope will not end up with
severe performance issues.

I do appreciate your input and will investigate the links you have
given me as a further resource of information.

Dec 8 '06 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Susan Bricker | last post by:
Greetings Experts ... I have a routine that is invoked when a command button is clicked. The button is located in a form that is tied to a table of Project records. Each Project Record has 0 to...
11
by: MLH | last post by:
If this is what MySQL is set to... SELECT DISTINCTROW qryVehiclesNowners5.SerialNum, qryVehiclesNowners5.VDescr, qryVehiclesNowners5.Owner, qryVehiclesNowners5.VehicleJobID ,...
3
by: KelHemp | last post by:
I have compiled data from 13 tables, one for each month of the year that hold 45 fields each, and another for employee information, that holds 16 fields. The database is intended to record hours and...
10
by: jonathanemil | last post by:
Hello, I am a 1st semester Computer Science student in a Python class. Our current assignment calls for us to read a list from a file, create a 2-dimensional list from the file, and check to see...
3
by: DrVitoti | last post by:
On that program the compiler says "parse error" on line 8, 10, 12 and 21, it also says "too many arguments" on lines 10, 12 and finally it says "at this port in" on lines 13, 14, 20 . How could I...
0
benchpolo
by: benchpolo | last post by:
I am currently modifying an existing DTS process by adding a new field in the Transformation task. This process queries data from SQL tables and import it to MSExcel. Steps 1. Drop the table...
1
by: Stodge | last post by:
Yet another SWIG question (YASQ!). I'm having a problem with using an abstract base class. When generating the Python bindings, SWIG thinks that all the concrete classes that derive from this...
1
by: Wiseman | last post by:
Hello, I am making a web page and have included a JavaScript named crazy clock. The page displays fine in IE but not in Firefox. The event console says: "event is not defined" at line 143....
18
reginaldmerritt
by: reginaldmerritt | last post by:
When opeing and closing a DAO recordset a few times i get the following error message: I've been google and forum investigating all day. The only thing i have found is information on...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.