Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Combinening data into a single field 1
- Thread starter erich13us
- Start date
-
1
- #2
- Thread starter
- #3
Followup the code code worked with only a small glitch. The middle field is a date field and it is automatically adding /'s. If I can capture the middle charactures, then I can figure a way to dispose of them. (I want
=(left([field],2)) & the 4th and 5th characture & (right[field],2))
=(left([field],2)) & the 4th and 5th characture & (right[field],2))
) & (right([FieldC],1))- Thread starter
- #5
The way you're doing it at the moment, the textbox is not a firld - that is, it won't be saved back into your database table, it is diplayed only on your form.
I am not an expert by any means, but I don't think it is good practice to write this calculated field back into your table. If you did this, then any change in any of the three fields that go to make up your textbox would not necessarily be reflected in the information held in the table. The way things are at the moment, the information in the textbox displayed on your form will always be accurate.
Again, I am not an expert, but I believe it would be a better idea for your primary key to be based on another unique field or, if your table doesn't currently have one, an autonumber field used specifically for the purpose of being a primary key.
HTH
Chris
I am not an expert by any means, but I don't think it is good practice to write this calculated field back into your table. If you did this, then any change in any of the three fields that go to make up your textbox would not necessarily be reflected in the information held in the table. The way things are at the moment, the information in the textbox displayed on your form will always be accurate.
Again, I am not an expert, but I believe it would be a better idea for your primary key to be based on another unique field or, if your table doesn't currently have one, an autonumber field used specifically for the purpose of being a primary key.
HTH
Chris
To follow up Krispi, and your question:
Can a calculated field be used as a Primary Key?
No. Nor should a calculated field be stored in a table.
If you find yourself in the situation of envisioning a three-part concatenation of data as a primary key, there is probably a flaw in your design.
HOWEVER, there is NO problem with setting the THREE component fields that you are combining as the primary key. A primary key CAN contain more than ONE field, in which case it is sometimes called a composite key.
I shy away from using autonumbering as a key, because it does NOT ensure uniqueness of records, which is one thing a primary key SHOULD do.
Jim
Me? Ambivalent? Well, yes and no....
Another free Access forum:
More Access stuff at
Can a calculated field be used as a Primary Key?
No. Nor should a calculated field be stored in a table.
If you find yourself in the situation of envisioning a three-part concatenation of data as a primary key, there is probably a flaw in your design.
HOWEVER, there is NO problem with setting the THREE component fields that you are combining as the primary key. A primary key CAN contain more than ONE field, in which case it is sometimes called a composite key.
I shy away from using autonumbering as a key, because it does NOT ensure uniqueness of records, which is one thing a primary key SHOULD do.
Jim
Me? Ambivalent? Well, yes and no....
Another free Access forum:
More Access stuff at
- Status
