Query with too many fields

[Task Database Nightmare]

Need your help.

I am trying to create a query using 4 different tables. When I try to
create, I get the "too many fields" error message. I tried to trick it by
creating a query with 2 tables then creating another query adding a third
table, etc. but get the same error message. There is only 1 duplicate field
in each table and yes all fields are necessary. Suggestions?

Tables are as follows:

Task Listing New - Main 62 fields
Task Listing New - Print Specs 100 fields
Task Listing New - Reorder 29 fields
Task Listing New - RFC 126 fields

From the query I am creating a form. Actually I already created the form and
was using one large table but had to add some fields and received the same
error message so my idea was to break the large table into the 4 tables
mentioned above and then create a query from which the form runs... but now I
am stuck again.

 

[Douglas J. Steele]

There's no way to increase the number of fields in a query to more than 255
regardless how many hoops you may go through.

Is there some way that you can use a form and subform (or subforms) to do
your updates?

 

[Task Database Nightmare]

If I create a form, how do I use multiple tables in a form so that the tables
are updated so I can create custom queries from the tables as I am also using
a switchboard.

 

[KARL DEWEY]

Task Listing New - Print Specs 100 fields
Maybe your tables could be organized in a different manner.
Are you using a separate field for each specification?
Post examples your tables and sample of data. Someone may have a suggestion
to revise to a workable solution.

 

[John W. Vinson]

Need your help.

I am trying to create a query using 4 different tables. When I try to
create, I get the "too many fields" error message. I tried to trick it by
creating a query with 2 tables then creating another query adding a third
table, etc. but get the same error message. There is only 1 duplicate field
in each table and yes all fields are necessary. Suggestions?

Tables are as follows:

Task Listing New - Main 62 fields
Task Listing New - Print Specs 100 fields
Task Listing New - Reorder 29 fields
Task Listing New - RFC 126 fields

From the query I am creating a form. Actually I already created the form and
was using one large table but had to add some fields and received the same
error message so my idea was to break the large table into the 4 tables
mentioned above and then create a query from which the form runs... but now I
am stuck again.

I would be VERY interested to see an Entity with 126 atomic, nonrepeating,
noninterdependent attributes!

I honestly believe that you must have some one to many, or many to many,
relationships embedded in each of these tables - and that you're storing data
in fieldnames. For example, I can easily believe that a project or product
might have 126 print specs - but you could handle them by having a 126 row
table of PrintSpecs, and third table with a field for the ProductID or
ProjectID or whatever it is, and for the PrintSpecID. Two fields, not 126, in
other words.

If I'm mistaken, I'd again be interested to see such an example. What are some
of your fields and their meanings?

 

[Duane Hookom]

John,
I read your reply hoping to see your line "Fields are expensive, records are
cheap" ;-)

 

[Task Database Nightmare]

I am sure the table could be created in a different way BUT the instructions
I have received from my boss is to create this database using Yes/No boxes so
all the choices are available at first view so a fillable field isn't an
option. So looking for some options based on what I have been told to create.
The other tables also have many Yes/No boxes.

Below is a sample of the fields in one of my tables:

Text 1 side Yes/No
Text 2 sides Yes/No
Text Head to Head Yes/No
Collated Yes/No
Stapled Yes/No

 

[John W. Vinson]

I am sure the table could be created in a different way BUT the instructions
I have received from my boss is to create this database using Yes/No boxes so
all the choices are available at first view so a fillable field isn't an
option. So looking for some options based on what I have been told to create.

If your boss told you to create an Excel spreadsheet without using any
calculations in cells would you agree to do so?

If s/he told you to create a Word document template without specifying any
formats would you agree to do so?

Your boss IS WRONG. Sorry, but that's just a fact.

The other tables also have many Yes/No boxes.

Below is a sample of the fields in one of my tables:

Text 1 side Yes/No
Text 2 sides Yes/No
Text Head to Head Yes/No
Collated Yes/No
Stapled Yes/No

What you could do, with a fair bit of effort and a little code, is create an
unbound Form with lots of checkboxes, and a set of normalized tables (e.g.
with fields like DocumentID as a link to a documents/jobs/projects table and
PrintSpecID, linked to a PrintSpecs table with field values such as
"Collated"); you would have code to parse through the form controls and update
the table.

Data *PRESENTATION* and data *STORAGE* are different tasks with different
requirements. You should not let data presentation requirements drive you into
creating an improper - and as you have seen, impractical! - table structure.