 |
 |
||||||
|
|||||||
| Tags: fields, many |
 |
06-05-2008, 12:12 PM
|
|||
|
|||
Re: too many fields
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. > > 
|
| Sponsored Links |
|
06-05-2008, 11:07 PM
|
|||
|
|||
|
Re: too many fields
> You would have the same problem with MSSQL, as its ADO that has the > field limit, not the database. True but when working with lots of data go with products made for the real world. My thought is sooner or later one has to be there, might as well do it now and reap the rewards and therefore avoid the pain. --
|
|
06-06-2008, 01:52 PM
|
|||
|
|||
|
Re: too many fields
Philo wrote:
>> You would have the same problem with MSSQL, as its ADO that has the >> field limit, not the database. > > True but when working with lots of data go with products made for the > real world. My thought is sooner or later one has to be there, might > as well do it now and reap the rewards and therefore avoid the pain. Completely agree with you there, just wanted him to be aware that if he changed to MSSQL it wouldn't fix the problem, but it would be a step in the right direction if he did that and changed the database design. Steve
|
|
07-23-2008, 10:11 AM
|
|||
|
|||
|
Re: too many fields
Hi Murray
My database is structured like this: table1 = Company Details table2 = Instruments table3 = InstrumentHistory It's the InstrumentHistory table that has to many fields. Each record in this table has 182 filed (oops) Checked_Against_Remark Cross_Checked_Rem Repair_Remark Ins_Res_Name_V1 Ins_Res_Name_V2 Ins_Res_Name_V3 Ins_Res_Tol_V1 Ins_Res_Tol_V2 Ins_Res_Tol_V3 Ins_Applied_V1 Ins_Applied_V2 Ins_Applied_V3 Ins_Reading_V1 Ins_Reading_V2 Ins_Reading_V3 Ins_PF_V1 Ins_PF_V2 Ins_PF_V3 Cont_Res_Name_V1 Cont_Res_Name_V2 Cont_Res_Name_V3 Cont_Res_Tol_V1 Cont_Res_Tol_V2 Cont_Res_Tol_V3 Cont_Applied_V1 Cont_Applied_V2 Cont_Applied_V3 Cont_Reading_V1 Cont_Reading_V2 Cont_Reading_V3 Cont_PF_V1 Cont_PF_V2 Cont_PF_V3 VoltAC_Name_V1 VoltAC_Name_V2 VoltAC_Name_V3 VoltAC_Tol_V1 VoltAC_Tol_V2 VoltAC_Tol_V3 VoltAC_Applied_V1 VoltAC_Applied_V2 VoltAC_Applied_V3 VoltAC_Reading_V1 VoltAC_Reading_V2 VoltAC_Reading_V3 VoltAC_PF_V1 VoltAC_PF_V2 VoltAC_PF_V3 VoltDC_Name_V1 VoltDC_Name_V2 VoltDC_Name_V3 VoltDC_Tol_V1 VoltDC_Tol_V2 VoltDC_Tol_V3 VoltDC_Applied_V1 VoltDC_Applied_V2 voltDC_Applied_V3 VoltDC_Reading_V1 VoltDC_Reading_V2 VoltDC_Reading_V3 VoltDC_PF_V1 VoltDC_PF_V2 VoltDC_PF_V3 CurrentAC_Name_V1 CurrentAC_Name_V2 CurrentAC_Name_V3 CurrentAC_Tol_V1 CurrentAC_Tol_V2 CurrentAC_Tol_V3 CurrentAC_Applied CurrentAC_Applied CurrentAC_Applied CurrentAC_Reading CurrentAC_Reading CurrentAC_Reading CurrentAC_PF_V1 CurrentAC_PF_V2 CurrentAC_PF_V3 CurrentDC_Name_V1 CurrentDC_Name_V2 CurrentDC_Name_V3 CurrentDC_Tol_V1 CurrentDC_Tol_V2 CurrentDC_Tol_V3 CurrentDC_Applied CurrentDC_Applied CurrentDC_Applied CurrentDC_Reading CurrentDC_Reading CurrentDC_Reading CurrentDC_PF_V1 CurrentDC_PF_V2 CurrentDC_PF_V3 Loop_Res_Name_V1 Loop_Res_Name_V2 Loop_Res_Name_V3 Loop_Tol_V1 Loop_Tol_V2 Loop_Tol_V3 Loop_Applied_V1 Loop_Applied_V2 Loop_Applied_V3 Loop_Reading_V1 Loop_Reading_V2 Loop_Reading_V3 Loop_PF_V1 Loop_PF_V2 Loop_PF_V3 PSC_PFC_Name_V1 PSC_PFC_Name_V2 PSC_PFC_Name_V3 PSC_PFC_Tol_V1 PSC_PFC_Tol_V2 PSC_PFC_Tol_V3 PSC_PFC_Applied_V PSC_PFC_Applied_V PSC_PFC_Applied_V PSC_PFC_Reading_V PSC_PFC_Reading_V PSC_PFC_Reading_V PSC_PFC_PF_V1 PSC_PFC_PF_V2 PSC_PFC_PF_V3 Earth_Ohms_Name_V Earth_Ohms_Name_V Earth_Ohms_Name_V Earth_Ohms_Tol_V1 Earth_Ohms_Tol_V2 Earth_Ohms_Tol_V3 Earth_Ohms_Applie Earth_Ohms_Applie Earth_Ohms_Applie Earth_Ohms_Readin Earth_Ohms_Readin Earth_Ohms_Reading_V3 Earth_Ohms_PF_V1 Earth_Ohms_PF_V2 Earth_Ohms_PF_V3 Earth_Bond_Name_V Earth_Bond_Name_V Earth_Bond_Name_V Earth_Bond_Tol_V1 Earth_Bond_Tol_V2 Earth_Bond_Tol_V3 Earth_Bond_Applie Earth_Bond_Applie Earth_Bond_Applie Earth_Bond_Readin Earth_Bond_Readin Earth_Bond_Readin Earth_Bond_PF_V1 Earth_Bond_PF_V2 Earth_Bond_PF_V3 Flash_Test_Name_V Flash_Test_Name_V Flash_Test_Name_V Flash_Test_Tol_V1 Flash_Test_Tol_V2 Flash_Test_Tol_V3 Flash_Test_Applie Flash_Test_Applie Flash_Test_Applie Flash_Test_Readin Flash_Test_Readin Flash_Test_Readin Flash_Test_PF_V1 Flash_Test_PF_V2 Flash_Test_PF_V3 RCD_Name_V1 RCD_Name_V2 RCD_Name_V3 RCD_Tol_V1 RCD_Tol_V2 RCD_Tol_V3 RCD_Applied_V1 RCD_Applied_V2 RCD_Applied_V3 RCD_Reading_V1 RCD_Reading_V2 RCD_Reading_V3 RCD_PF_V RCD_PF_V2 "Murray *ACE*" <forums@HAHAgreat-web-sights.com> wrote in message news:g28hhi$k$1@forums.macromedia.com... > 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. >> >> >
|
|
09-28-2008, 01:03 AM
|
|||
|
|||
|
Re: too many fields
Hi Murray
My database is structured like this: table1 = Company Details table2 = Instruments table3 = InstrumentHistory It's the InstrumentHistory table that has to many fields. Each record in this table has 182 filed (oops) Checked_Against_Remark Cross_Checked_Rem Repair_Remark Ins_Res_Name_V1 Ins_Res_Name_V2 Ins_Res_Name_V3 Ins_Res_Tol_V1 Ins_Res_Tol_V2 Ins_Res_Tol_V3 Ins_Applied_V1 Ins_Applied_V2 Ins_Applied_V3 Ins_Reading_V1 Ins_Reading_V2 Ins_Reading_V3 Ins_PF_V1 Ins_PF_V2 Ins_PF_V3 Cont_Res_Name_V1 Cont_Res_Name_V2 Cont_Res_Name_V3 Cont_Res_Tol_V1 Cont_Res_Tol_V2 Cont_Res_Tol_V3 Cont_Applied_V1 Cont_Applied_V2 Cont_Applied_V3 Cont_Reading_V1 Cont_Reading_V2 Cont_Reading_V3 Cont_PF_V1 Cont_PF_V2 Cont_PF_V3 VoltAC_Name_V1 VoltAC_Name_V2 VoltAC_Name_V3 VoltAC_Tol_V1 VoltAC_Tol_V2 VoltAC_Tol_V3 VoltAC_Applied_V1 VoltAC_Applied_V2 VoltAC_Applied_V3 VoltAC_Reading_V1 VoltAC_Reading_V2 VoltAC_Reading_V3 VoltAC_PF_V1 VoltAC_PF_V2 VoltAC_PF_V3 VoltDC_Name_V1 VoltDC_Name_V2 VoltDC_Name_V3 VoltDC_Tol_V1 VoltDC_Tol_V2 VoltDC_Tol_V3 VoltDC_Applied_V1 VoltDC_Applied_V2 voltDC_Applied_V3 VoltDC_Reading_V1 VoltDC_Reading_V2 VoltDC_Reading_V3 VoltDC_PF_V1 VoltDC_PF_V2 VoltDC_PF_V3 CurrentAC_Name_V1 CurrentAC_Name_V2 CurrentAC_Name_V3 CurrentAC_Tol_V1 CurrentAC_Tol_V2 CurrentAC_Tol_V3 CurrentAC_Applied CurrentAC_Applied CurrentAC_Applied CurrentAC_Reading CurrentAC_Reading CurrentAC_Reading CurrentAC_PF_V1 CurrentAC_PF_V2 CurrentAC_PF_V3 CurrentDC_Name_V1 CurrentDC_Name_V2 CurrentDC_Name_V3 CurrentDC_Tol_V1 CurrentDC_Tol_V2 CurrentDC_Tol_V3 CurrentDC_Applied CurrentDC_Applied CurrentDC_Applied CurrentDC_Reading CurrentDC_Reading CurrentDC_Reading CurrentDC_PF_V1 CurrentDC_PF_V2 CurrentDC_PF_V3 Loop_Res_Name_V1 Loop_Res_Name_V2 Loop_Res_Name_V3 Loop_Tol_V1 Loop_Tol_V2 Loop_Tol_V3 Loop_Applied_V1 Loop_Applied_V2 Loop_Applied_V3 Loop_Reading_V1 Loop_Reading_V2 Loop_Reading_V3 Loop_PF_V1 Loop_PF_V2 Loop_PF_V3 PSC_PFC_Name_V1 PSC_PFC_Name_V2 PSC_PFC_Name_V3 PSC_PFC_Tol_V1 PSC_PFC_Tol_V2 PSC_PFC_Tol_V3 PSC_PFC_Applied_V PSC_PFC_Applied_V PSC_PFC_Applied_V PSC_PFC_Reading_V PSC_PFC_Reading_V PSC_PFC_Reading_V PSC_PFC_PF_V1 PSC_PFC_PF_V2 PSC_PFC_PF_V3 Earth_Ohms_Name_V Earth_Ohms_Name_V Earth_Ohms_Name_V Earth_Ohms_Tol_V1 Earth_Ohms_Tol_V2 Earth_Ohms_Tol_V3 Earth_Ohms_Applie Earth_Ohms_Applie Earth_Ohms_Applie Earth_Ohms_Readin Earth_Ohms_Readin Earth_Ohms_Reading_V3 Earth_Ohms_PF_V1 Earth_Ohms_PF_V2 Earth_Ohms_PF_V3 Earth_Bond_Name_V Earth_Bond_Name_V Earth_Bond_Name_V Earth_Bond_Tol_V1 Earth_Bond_Tol_V2 Earth_Bond_Tol_V3 Earth_Bond_Applie Earth_Bond_Applie Earth_Bond_Applie Earth_Bond_Readin Earth_Bond_Readin Earth_Bond_Readin Earth_Bond_PF_V1 Earth_Bond_PF_V2 Earth_Bond_PF_V3 Flash_Test_Name_V Flash_Test_Name_V Flash_Test_Name_V Flash_Test_Tol_V1 Flash_Test_Tol_V2 Flash_Test_Tol_V3 Flash_Test_Applie Flash_Test_Applie Flash_Test_Applie Flash_Test_Readin Flash_Test_Readin Flash_Test_Readin Flash_Test_PF_V1 Flash_Test_PF_V2 Flash_Test_PF_V3 RCD_Name_V1 RCD_Name_V2 RCD_Name_V3 RCD_Tol_V1 RCD_Tol_V2 RCD_Tol_V3 RCD_Applied_V1 RCD_Applied_V2 RCD_Applied_V3 RCD_Reading_V1 RCD_Reading_V2 RCD_Reading_V3 RCD_PF_V RCD_PF_V2 "Murray *ACE*" <forums@HAHAgreat-web-sights.com> wrote in message news:g28hhi$k$1@forums.macromedia.com... > 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. >> >> >
|
|
| Thread Tools | |
| Display Modes | |
|
|
- Contact Us
-|-
Adobe Dreamweaver Forums -|-
Archive -|-
Top -|-Rules/Disclaimer-|-Help/Support-|-Advertise
Linear Mode
