error message that says too many fields

G

Guest

I am trying to save my table. Each time I do, I get an error message that
says too many fields defined. Right now I have 75 fields--I thought the
limit was 255. What is going on?
 
R

Rick Brandt

DeannaLynne said:
I am trying to save my table. Each time I do, I get an error message
that says too many fields defined. Right now I have 75 fields--I
thought the limit was 255. What is going on?

There is also limit on the total bytes in a row (2KB I Think).

Also, the 255 count also includes any fields you have added and subsequently
deleted or renamed.
 
R

Rick B

First, 75 fields is probably WAY too many.

A properly designed database table should have 15 or 20 fields at the most.
Are you sure your design is correct? Are you committing "spreadsheet"?

You might want to share your database design with us and we will offer some
help.
 
G

Guest

Thanks, Rick, but I don't think I created more than 255 in total. If I did,
how do I clear the ones I have deleted? How do I check to see if the issue
is more than 2KB in a row?
 
G

Guest

admittedly, I don't know much about access--so I am probably committing
multiple errors!! It is my boss's idea to use access--I don't know why we
aren't using a statistical package being that the goal is to do a qualitative
analysis of the data that I am entering (but that is why he makes the big
bucks, I guess). How can I share my database deisng with you?
 
R

Rick B

Just tell us what you are doing. What tables do you have, and what fields
are in each table? How are the tables related to each other.

For example, a contact management database might have one table that stores
information about people. Another that stores information about Companies.
Another that ties people to the companies for which they work. Another that
stores phone calls made and details about each call. This call table would
be linked to the person you called and that would be further linked to the
company for which they work.

Creating a flat design would put all this in one table, and every single
time you logged a call, you'd also have to put the company data and person
data. A flat design very often leads to duplicate data in your tables.
That is one way to spot a bad design.

Another issue can be including data in your fields. Lets say you want to
track payments made by customers. The customer gives you a check for $500.
$400 is to cover the rent, $50 is to pay a late fee, and $50 is to pay for a
new lock on their front door that they requested. A poorly designed table
might have all the fields for the payment data (customer, date, amount,
etc.) and then would have a field for each type of service being paid (rent,
deposit, late fee, etc.). For most payments, only a few of those fields
would be used. This generally indicates a bad design. Another key here is
that the field names contain data. This is normally wrong. A better way
would be to create a main table for the payment, and a separate table for
details. If the receipt only pays rent, you'll have a record in each table.
If it pays rent and a late fee, you will have one record in your main table
and two in your details table. The details table would have the Rect
Number, the ItemAmount, and the ItemDescription or ItemType. You might even
have a third table to store the valid ItemTypes!

Post back and we will try to help you (unless this message gave you some
ideas).
 
E

Ed Warren

You might start with where you want to end up. Most of us don't understand
'qualitative' and 'statistical package' together.

To me a qualitative study is a formal method of knowledge exploration using
tools that are very much text based (NUDIST being one) and has little to do
with a 'statistical package'.

If your fields look something like:
SubjectID, observation1, observation2, observation3 where each observation
is basically the same data type then you have a spreadsheet design, and it
should be changed to a relational design.


Ed Warren.
 
R

Rick B

In Ed's example, You'd have a table for the subjects and ONE table for the
Observations. If a subject had 5 observations, then he'd have five records
in the observation table. But, the table itself would be very generic in
it's design.
 
J

John Spencer

Try doing a Compact and Repair on the database (look under the tool menu).
That will reset the table field count to 75.

As far as the 2000 byte limit on a row of data - you won't get any errors
until you actually enter data into a row that exceeds the limit.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top