Yes perhaps. That's why I need help :) I'm not explaining something, which is why I'm trying to do this in the first place.
In the child table, users won't be creating one record at a time. I intend for them to import batches of new records, possibly hundreds at a time, either with an Excel sheet or just copy/paste using 'import from clipboard'.
Column A will be the [RefID] and Column B will be the associated job, [Job #].
The user will know what the Job # is because that record will have already been created in the parent table prior to them importing into the child table.
So, as part of the one-to-many relationship, in the parent table I can see how many [RefID] records are related to a single [Job #].
But in order to do this, doesn't [Job #] have to be the key field in the parent table? I have found so far that if I keep [Record ID#] as the key field then this is what needs to be in Column B when a user imports to the child table and that isn't going to work for my app.
[Job #] is going to be critical in what I ultimately want to do later, which is to use [Job #] to relate records together across multiple apps.
It's very much like [Record ID#] but it has to be 4 digits. Not my decision, it's just how it has to be. So that is what is really causing me the headache. Otherwise yes, I'd just use [Record ID#].