Multiple fields the same kind of name

[resolva]

Hey all,

I am designing a table however I don't know what is the best way of doing this.

Basically I need a form so that you can enter an ingredient, its conc% and its level.

At the moment I have soo many fields in the table as I have done it like this. Of course say AqueousPhase1 will relate to conc1.

AqueousPhase1
AqueousPhase2
AqueousPhase3
AqueousPhase4
AqueousPhase5
conc1
conc2
conc3
conc4
conc5

Is there a better way of doing it than this or do you have to have a new field for each data entered?

Regards

 

[Uncle Gizmo]

I would suggest you have a look at this post here:


Which demonstrates how to use a simple tool I created, (a form) this form is designed to solve some of the problems I believe you are having.

 

[resolva]

Hi, thank you for the reply.

I don't think that is what I am trying to do.

I am looking to just setup the table in the database with the fields. It seems like I have a stupid amount of fields with the common name.

 

[Uncle Gizmo]

How many AqueousPhase5 fields do you have?

How many conc1 Fields?

Are there any other Fields?

 

[Uncle Gizmo]

Also read this Thread:

 

[Uncle Gizmo]

...............


Double post (removed content)

 

[resolva]

Thank you for the great reply!

I have attached a screenshot of the current form which was used on the database before.

As you can see for example in the Aqueous phase there is the ingredients listed HW for example and next to that there is conc %.

At the moment each of them is its own field within the table. So it took forever to build that database because there is 8 Aqueous fields, 8 conc% for each aqueous field etc. Then there is 8 fields for the levels aswell.

Can you see what I mean?

 

[Uncle Gizmo]

you Say: I don't think that is what I am trying to do. In particular where does the following "Not" fit with your design...

I have pointed you in the right direction (from the information you have provided) now what I am saying is, don't dismiss what I say, in other words don't put the ball back in my court, read what I have suggested you read, and come back with a positive reason why it doesn't work for you.

I'm here to try and point you in the right direction. If what I consider is the right direction does not fit with what you want to, at least do me the honor of pointing out where my suggestion doesn't meet your requirements.

This way I will get a better understanding of what you want, and you will get a better answer.

In particular read this:

How?
If you look at the original layout of the data above you can ask questions about it, is there any data in the original table that is related? Looking at it, I would suspect all of the boolean columns (the check box columns, yes/no data) they are all the same, so they are a likely candidate for a separate table. And indeed there is an obvious name for this new table, they are all “subjects” that the student is or could take.

The New Table
So now you have a name for the new table, “Subjects” and to link it to the data remaining in the original table, (first name,- last name) it will need to have a field which contains a match to the RecordUniqueID field. For this example let’s call this “MatchingID” then you need a field to record the subject and another field to record whether it is true or false. For the purposes of this demonstration I have terms these “TransposedSubject” and “TransposedData” and you can see what this should look like below:

 

[resolva]

Uncle Gizmo, In the post before I showed you a screenshot of what I am trying to do.

I don't think it relates to using your way of excel in access unless I am completely mistaken. I apologise for not being specific enough in the previous post.

regards

 

[Uncle Gizmo]

>>>I don't think it relates to using your way of excel in access unless I am completely mistaken<<<

The posts I directed you to have nothing to do with excel, I chose the title "excel" in access, using the true meaning of excel. The tenuous relationship to excel is that many people copy flat file tables directly into MS Access and expect them to work in the same way they did in excel. That's the only connection with excel.

What I am saying is, in my opinion, what I have suggested is the way to go, I still think it is. What I want from you is the reason(s) you don't think it's the right way to go.

I don't want from you the comments like "I don't think that is what I am trying to do", although this is a perfectly correct from your point of view, and I completely understand why you made the comment, it in no way helps me to see what you want does it?

Put it another way, you say, no that's not what I want, I now have the option to Either:

examine your database in detail and enhance my argument that this is the right way to go, or find the issue that makes the method I suggest unsuitable.

However I am more likely to think "well I've done my best I will leave it at that"