It would help to know more details about your basic design. My best guess is that you have this structure, but with your names instead of mine:
Devices::__pkDeviceID = Join::_fkDeviceID
AnotherTable::__pkAnotherTableID = Join::_fkAnotherTableID
For an explanation of the notation that I am using, see the first post of: Common Forum Relationship and Field Notations Explained
I do not, however, recommend that you use your user entered serial number in place of __pkDeviceID. That should always be an internally, automatically generated unique ID such as an auto-entered serial number.
But what you can do, is create a second Tutorial: What are Table Occurrences? for Devices and link it to Another table by this user entered serial number:
AnotherTable::DeviceSerial = Devices|DeviceSerial::DeviceSerial
And enable "Allow creation of records via this relationship" for Devices|DeviceSerial.
Then the following script can be performed off an OnObjectSave script trigger on the AnotherTable::DeviceSerial field:
If [ IsEmpty ( Devices|DeviceSerial::DeviceSerial ) // no such device in table ]
Set Field [ Devices|DeviceSerial::DeviceSerial ; AnotherTable::DeviceSerial ]
Set Field [ Join::_fkAnotherTableID ; AnotherTable::__pkAnotherTableID ]
Set Field [Join::_fkDeviceID ; Devices|DeviceSerial::_pkDeviceID ]
You have the structure correct (as well as almost exactly my key naming). Thanks for the link; I'll use that notation henceforth.
And thank you for the advice on PKs. I was unsure of that - serial number seemed OK, but I think I understand the logic behind using an auto-generated one. I'm still learning forms, stnadard/ best practices etc.
I assumed some possibility that FM wouldn't require a script to create a record in this fashion when both value Uniqueness test and creation of records via relationship are configuration items. But, one never knows. I will gratefully follow your suggestion. THANK YOU!
The script is needed to manage the data in the join table. And I'm not convinced that you need a join table, but then I know little about your database.
The risk to using any externally generated value as your PK value is that your database is then at the mercy of how that value is generated and entered into your computer. Should that value be generated incorrectly or be entered into your system incorrectly, fixing the issue in your datatabase can break links to related records if not done with care and attention to detail and a mistake can scramble things up pretty badly.
Even if you are scanning barcodes to enter that serial number, there is still the possibility, though much less likely, of an error--such as encountering a damaged label and having to manually enter the code.
So if you don't use the externally supplied serial number as your PK, any such issues become simple data entry edits.