Yes, I think I understand better. But it seems clearer now, to me, that (along the lines of what June is saying as well), you're not yet at the place that would lead to this question. You're further back..at the extremely critical juncture of table design. (the first step). Nothing else matters until the tables are properly designed. It sounds like (at least), you should have a table for Customers, WarrantyRequests, and Properties. Customers-to-WarrantyRequests is One-To-Many. CustomerID is primary key in Customer table (autonumber), CustomerID is a foreign key in WarrantyRequests table (Long Integer). Properties have a separate table too, in case a customer has many properties. WarrantyRequests will have the most data, and will have a snowflake type of modeling out towards Properties and Customers which will have fewer rows.
All of the (3) keys I've mentioned so far should be autonumbers and nothing but autonumbers, "anonymous" - with no significance attributed to them of any kind other than being primary and foreign keys for joining in queries.

Whether you also want a "natural key" type of thing because your business users get warm fuzzies when they see some concatenated value from which they can extrapolate interesting information (which of course they could also get from you displaying in a query/form/report), that's fine - but in creating one of these, don't replace the general principles of anonymous autonumbers for primary and foreign keys.



And most of all, go back to the Table design phase and get it 100% right the first time as best as you can.