Why not have two tables instead of one?

Table one would describe the person taking the test with a record ID and
table two would be the results table keyed to each record ID? With a design
like this, one record in table one could be linked to any number of records
in table two, each of which contains only the fields necessary to describe a
given result. Your field count would drop dramatically.

--
Murray --- ICQ 71997575
Adobe Community Expert
(If you *MUST* email me, don't LAUGH when you do so!)
==================
http://www.projectseven.com/go - DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs, Tutorials & Resources
==================


"Andy" <andy@work.com> wrote in message
news:g28fnd$rgn$1@forums.macromedia.com...
> Thanks Guys
> Each of the fields is a possible reading from a test result. Not all
> fields need to van a value, but the option has to be available.
> For instance, the user would enter his/her test results in to the relevant
> text fields. Not all results will have all values.
> Each text field is a unique reading and not duplicated in the database.
> I should be using MSSQL i know, but i have yet to make the leap and my
> knowledge is limited where MSSQL is concerned.
>
> Thanks for the advice
>
> Andy
>
>
>
>
> "Philo" <meansyou@nospam.net> wrote in message
> news:g260c5$32l$1@forums.macromedia.com...
>>I am with David, you have a desgin problem. I see a whole series of 1,
>> 2 & 3 on your field names. That means there should be a way to
>> normalize that where you would have 3 records, one for each of the
>> numbers 1 thru 3.
>>
>> A 160 fields to complete on a form seems like a huge time consuming
>> task for a user to complete. There should be someway for the user to
>> break it up and from what little I can see it looks like it could be
>> broken into thirds.
>>
>> I would also consder changing to MSSQL. Access is slow and prone to
>> many problems including corrupted files.
>
>