Would depend on whether or not you've already designed table(s) to support this. IMO, if you are transitioning from old to new part numbers, you probably should have a new table to record the transitions; something like
OldPartNo |
|
|
NewPartNo |
|
|
OpnIDpk |
|
|
NpnIDpk |
OpnIDfk |
NewPartNo |
1 |
11234 |
|
1 |
1 |
43211 |
2 |
23456 |
|
2 |
2 |
65432 |
3 |
5678 |
|
3 |
3 |
8765 |
4 |
14789 |
|
4 |
4 |
98741 |
Ignore that the new part number pk field values here are the same as anything else. The important matches would be the old PK id's (left red) match the old FK values (right red), thus you can link the new and old part numbers. That way, you could find/know the other as long as you know one.
If you haven't set it up this way and a part number can ever get a 3rd value, then you will have problems.
The direct answer to your question may be that in the AfterUpdate event of the 2nd combo, you will have to execute an UPDATE sql to write those values to your table. However, I don't understand how there can be 3 tables providing choices when there are only 2 components - old and new numbers.
The idea is to get the user input to copy
all the data (3 tables) of Old to New.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.