I have a table set up this way. *LOTS* LOT - Text Field and Primary key GRADE - Text Field .... .... .... Our LOT identifiers are unique and are a concatination of the day of the year, 1-365), two digit year, single letter signifiying lot order A, B, C used for production, two digit code to signify operator, single digit to signify shift, and single character to signify machine. Originaly I have the table set up as *LOTS* LOT - Text Field (only day, year part, and order) and Primary key OPER - Text Field SHIFT - Text Field MACHINE - Text Field GRADE - Text Field .... .... .... I also had tables for OPER, SHIFT and Machine *OPER ID* OPER - Text Field and primary Key First Name - Text .... .... *SHIFT* SHIFT - Text Field and primary Key Start time - date/time end time - date/time .... .... *MACHINE* MACH - Text Field primary key MACHINE DETAILS - Memo .... .... These tables were linked to limit the data that could be entered on the main table to real operators, shifts and machines. This worked great UNTIL I realized that the LOT could be repeated if the same operator produced material on more that one machine at the same time. This is very rare but does happen. Therfore I concated all the fileds together into the new LOT. To validate the LOT data entry some code is used to pull the LOT apart and compare each part with the corisponding table of allowable entries. When I run reports or querries that use the information in these orphaned tables I also must write code to pull apart the LOT and get the correct part. My question is was their a better way to solve my original issue? I thought about setting a new primary key in the original table that was an auto number. HOWEVER, the users af the data base were already grumbling about having to enter each part ofhte LOT seperatly. So combining it made some sense make them happy. But I fear I may have set myself up for bigger issues down the road. Any other ideas as to what i should have done?