One to may Or One to One? (350 fields all static)

I want you all to know that I am not going to hire Steve for anything after
reading all of your caring responses. I appreciate you guys like you guys
can't believe. I only wish that Microsoft would compensate you guys with
Cruises and vacation trips...
Although I got the continuation of the fields to extend into another table
successfully I am considering changing the table structure in the next
revision. 250+ fields are required to describe one record because each record
tracks an application (someone applying for a job) that has that many fields.
Changes will be made to the record over time however I plan on tracking the
changes with an audit table. I am really familiar with one-to-many tables and
forms however by using them it will change the look of the data entry form
which needs to stay the same as the paper format that the approvers of the
applications are used to...


Iram/mcp




"John W. Vinson" wrote:

On Sat, 25 Jul 2009 19:15:01 -0700, Iram
wrote:

Hello.
I am creating a table that requires more than 250 fields (total of about 350
fields). All of these fields are required per record.

As everyone else has said, this table design IS WRONG on its face.

Please post the names and meanings of a few of these fields. I'm all but
certain that you have one or more on-to-many relationships embedded in each
record. "Fields are expensive, records are cheap"; you may well need to invest
some time and effort in changing the structure of your tables, but adding new
fields ad infinitum is absolutely the WRONG way to go, and will get you in no
end of trouble.
--

John W. Vinson [MVP]

Trying to structure your table to match a paper format is a common mistake.
The paper display should never dictate the actual data storage.

I would consider creating tables like:

tblApplication (one record per application)
appAppID autonumber primary key
appFirstName
appLastName
appRecvdDate
app...

tblAttribute (one record corresponding with previous many fields)
attAttID autonumber primary key
attName values such as "highest education level", "Salary request",...
attActive yes/no

tblAppAttribs (possibly 300+ records for each applicant
apaApAID autonumber primary key
apaAppID links to tblApplication.appAppID
apaAttID links to tblAttribute.attAttID
apaValue values such as "HS Grad", "BS", "GED",...

This solution would allow you to add attributes without changing structures.
There is a similar structure in "At Your Survey"
http://www.rogersaccesslibrary.com/f...osts.asp?TID=3 and Employee
Evaluation http://www.rogersaccesslibrary.com/f...sts.asp?TID=15.

--
Duane Hookom
Microsoft Access MVP


"Iram" wrote:

I want you all to know that I am not going to hire Steve for anything after
reading all of your caring responses. I appreciate you guys like you guys
can't believe. I only wish that Microsoft would compensate you guys with
Cruises and vacation trips...
Although I got the continuation of the fields to extend into another table
successfully I am considering changing the table structure in the next
revision. 250+ fields are required to describe one record because each record
tracks an application (someone applying for a job) that has that many fields.
Changes will be made to the record over time however I plan on tracking the
changes with an audit table. I am really familiar with one-to-many tables and
forms however by using them it will change the look of the data entry form
which needs to stay the same as the paper format that the approvers of the
applications are used to...


Iram/mcp




"John W. Vinson" wrote:

On Sat, 25 Jul 2009 19:15:01 -0700, Iram
wrote:

Hello.
I am creating a table that requires more than 250 fields (total of about 350
fields). All of these fields are required per record.

As everyone else has said, this table design IS WRONG on its face.

Please post the names and meanings of a few of these fields. I'm all but
certain that you have one or more on-to-many relationships embedded in each
record. "Fields are expensive, records are cheap"; you may well need to invest
some time and effort in changing the structure of your tables, but adding new
fields ad infinitum is absolutely the WRONG way to go, and will get you in no
end of trouble.
--

John W. Vinson [MVP]

Thanks Duane!
Your info and links helped me think about my table structure and how I need
to change my approach.



Thanks again.


Iram/mcp



"Duane Hookom" wrote:

Trying to structure your table to match a paper format is a common mistake.
The paper display should never dictate the actual data storage.

I would consider creating tables like:

tblApplication (one record per application)
appAppID autonumber primary key
appFirstName
appLastName
appRecvdDate
app...

tblAttribute (one record corresponding with previous many fields)
attAttID autonumber primary key
attName values such as "highest education level", "Salary request",...
attActive yes/no

tblAppAttribs (possibly 300+ records for each applicant
apaApAID autonumber primary key
apaAppID links to tblApplication.appAppID
apaAttID links to tblAttribute.attAttID
apaValue values such as "HS Grad", "BS", "GED",...

This solution would allow you to add attributes without changing structures.
There is a similar structure in "At Your Survey"
http://www.rogersaccesslibrary.com/f...osts.asp?TID=3 and Employee
Evaluation http://www.rogersaccesslibrary.com/f...sts.asp?TID=15.

--
Duane Hookom
Microsoft Access MVP


"Iram" wrote:

I want you all to know that I am not going to hire Steve for anything after
reading all of your caring responses. I appreciate you guys like you guys
can't believe. I only wish that Microsoft would compensate you guys with
Cruises and vacation trips...
Although I got the continuation of the fields to extend into another table
successfully I am considering changing the table structure in the next
revision. 250+ fields are required to describe one record because each record
tracks an application (someone applying for a job) that has that many fields.
Changes will be made to the record over time however I plan on tracking the
changes with an audit table. I am really familiar with one-to-many tables and
forms however by using them it will change the look of the data entry form
which needs to stay the same as the paper format that the approvers of the
applications are used to...


Iram/mcp




"John W. Vinson" wrote:

On Sat, 25 Jul 2009 19:15:01 -0700, Iram
wrote:

Hello.
I am creating a table that requires more than 250 fields (total of about 350
fields). All of these fields are required per record.

As everyone else has said, this table design IS WRONG on its face.

Please post the names and meanings of a few of these fields. I'm all but
certain that you have one or more on-to-many relationships embedded in each
record. "Fields are expensive, records are cheap"; you may well need to invest
some time and effort in changing the structure of your tables, but adding new
fields ad infinitum is absolutely the WRONG way to go, and will get you in no
end of trouble.
--

John W. Vinson [MVP]

Iram,

On behalf of everyone (well except Steve), and I am sure I am not speaking
out of turn... Thank you for the kind words!!!

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

"Iram" wrote in message
...
I want you all to know that I am not going to hire Steve for anything after
reading all of your caring responses. I appreciate you guys like you guys
can't believe. I only wish that Microsoft would compensate you guys with
Cruises and vacation trips...
Although I got the continuation of the fields to extend into another table
successfully I am considering changing the table structure in the next
revision. 250+ fields are required to describe one record because each
record
tracks an application (someone applying for a job) that has that many
fields.
Changes will be made to the record over time however I plan on tracking
the
changes with an audit table. I am really familiar with one-to-many tables
and
forms however by using them it will change the look of the data entry form
which needs to stay the same as the paper format that the approvers of the
applications are used to...


Iram/mcp




"John W. Vinson" wrote:

On Sat, 25 Jul 2009 19:15:01 -0700, Iram
wrote:

Hello.
I am creating a table that requires more than 250 fields (total of about
350
fields). All of these fields are required per record.

As everyone else has said, this table design IS WRONG on its face.

Please post the names and meanings of a few of these fields. I'm all but
certain that you have one or more on-to-many relationships embedded in
each
record. "Fields are expensive, records are cheap"; you may well need to
invest
some time and effort in changing the structure of your tables, but adding
new
fields ad infinitum is absolutely the WRONG way to go, and will get you
in no
end of trouble.
--

John W. Vinson [MVP]

Could be worse. Iram could have been given advice to upgrade to SQL
Server......
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.


"John... Visio MVP" wrote:

The problem is that posters come to these newsgroups and are assaulted by
out local troll, unaware of his reputation.

John... Visio MVP
"Gina Whipp" wrote in message
...
This is really pathetic... This is the third or maybe fourth time Steve
has approached Iram for work in a newsgroup that provides FREE services.
That alone would make me suspect!

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

"John... Visio MVP" wrote in message
...
Iram, ... and you would definitely be wasting your money if you take
stevie up on his offer. These newsgroups are for FREE peer to peer
support and anyone who can not respect the basic rules of these
newsgroups is NOT someone you should trust.

John.. Visio MVP
"Steve" help_available_at_very_reasonable_rates@contactme .com wrote in
message m...
Hello Iram,

You said ....
it would of changed the layout of the print form drastically from what
it is now and which I can't change.

Once you have the correct tables, you would create a query that includes
the appropriate tables so that the query includes all the fields you
want in the report. Then you use this query as the record source of the
report. The report would be the same as itis now.

Consider that you are wasting your time and effort continuing with the
current table. Eventually everything will need to be redone.

Be assured that my fee to help you will be very modest. Contact me and
let's get your tables right.

Steve


"Iram" wrote in message
...
I will keep you in mind for I know I will need it and would pay you. I
did
find a work around afterall. I did join the two tables and I was able
to
continue the records by...

On a "Form" that deals wth the second table (continuation table) I made
the
common field/joined field's (one to one) "Default" setting to be the
same as
whatever is common field in the first form thus creating the identical
common
data in the second field when I opened that secondary form.
Does this make sense?

Some day when I got money I sure would like to contact you for
consulting on
a better aproach for 350 fields that relate to one record and how to
audit
changes to any of thte 350 fields. I am currently doing this project
for my
church. Some of the fields are reoccuring and I know how to make
subforms and
subtables however it would of changed the layout of the print form
drastically from what it is now and which I can't change.


Thanks.
Steve.


"Steve" wrote:

Iram,

350 fields! Unequivocably the design of your tble is incorrect. You
say in
your next post that time is of the essence. I provide help with Access
applications for a modest fee. Contact me if you want someone to
design your
tables for you. My fee will be very modest.

Steve




"Iram" wrote in message
...
Hello.
I am creating a table that requires more than 250 fields (total of
about
350
fields). All of these fields are required per record. When I
couldn't
create
any more fields because of the limit I figured that I could create
another
table and extend the fields into it by joining a common field in
both
tables
using a one to one relationship. The problem is that when I create a
record
in the primary table I can't get the joined table to create auto
create
the
same common field like a One to Many relationship does
automatically. How
do
I mitigate this? I need about alot of fields for one record. Later I
am
going
to need help creating an audit table for all 350 fields joined
across two
tables, but that's going to be a whole new question all on its own.


Thanks.
Iram/mcp

....still laughing!

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

"Jerry Whittle" wrote in message
...
Could be worse. Iram could have been given advice to upgrade to SQL
Server......
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.


"John... Visio MVP" wrote:

The problem is that posters come to these newsgroups and are assaulted by
out local troll, unaware of his reputation.

John... Visio MVP
"Gina Whipp" wrote in message
...
This is really pathetic... This is the third or maybe fourth time
Steve
has approached Iram for work in a newsgroup that provides FREE
services.
That alone would make me suspect!

--
Gina Whipp

"I feel I have been denied critical, need to know, information!" -
Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm

"John... Visio MVP" wrote in message
...
Iram, ... and you would definitely be wasting your money if you take
stevie up on his offer. These newsgroups are for FREE peer to peer
support and anyone who can not respect the basic rules of these
newsgroups is NOT someone you should trust.

John.. Visio MVP
"Steve" help_available_at_very_reasonable_rates@contactme .com wrote
in
message m...
Hello Iram,

You said ....
it would of changed the layout of the print form drastically from
what
it is now and which I can't change.

Once you have the correct tables, you would create a query that
includes
the appropriate tables so that the query includes all the fields you
want in the report. Then you use this query as the record source of
the
report. The report would be the same as itis now.

Consider that you are wasting your time and effort continuing with
the
current table. Eventually everything will need to be redone.

Be assured that my fee to help you will be very modest. Contact me
and
let's get your tables right.

Steve


"Iram" wrote in message
...
I will keep you in mind for I know I will need it and would pay you.
I
did
find a work around afterall. I did join the two tables and I was
able
to
continue the records by...

On a "Form" that deals wth the second table (continuation table) I
made
the
common field/joined field's (one to one) "Default" setting to be the
same as
whatever is common field in the first form thus creating the
identical
common
data in the second field when I opened that secondary form.
Does this make sense?

Some day when I got money I sure would like to contact you for
consulting on
a better aproach for 350 fields that relate to one record and how to
audit
changes to any of thte 350 fields. I am currently doing this project
for my
church. Some of the fields are reoccuring and I know how to make
subforms and
subtables however it would of changed the layout of the print form
drastically from what it is now and which I can't change.


Thanks.
Steve.


"Steve" wrote:

Iram,

350 fields! Unequivocably the design of your tble is incorrect. You
say in
your next post that time is of the essence. I provide help with
Access
applications for a modest fee. Contact me if you want someone to
design your
tables for you. My fee will be very modest.

Steve




"Iram" wrote in message
...
Hello.
I am creating a table that requires more than 250 fields (total
of
about
350
fields). All of these fields are required per record. When I
couldn't
create
any more fields because of the limit I figured that I could
create
another
table and extend the fields into it by joining a common field in
both
tables
using a one to one relationship. The problem is that when I
create a
record
in the primary table I can't get the joined table to create auto
create
the
same common field like a One to Many relationship does
automatically. How
do
I mitigate this? I need about alot of fields for one record.
Later I
am
going
to need help creating an audit table for all 350 fields joined
across two
tables, but that's going to be a whole new question all on its
own.


Thanks.
Iram/mcp

Iram wrote:

I want you all to know that I am not going to hire Steve for anything after
reading all of your caring responses. I appreciate you guys like you guys
can't believe.

Thanks for your kind words.

I only wish that Microsoft would compensate you guys with
Cruises and vacation trips...

So do we! smile

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/