No scripts needed.
If you are making changes you really should use Get(UUID) for your primary keys. Use some other identifier for your equipment identification. The keys should not be understandable and should never change or have duplicates.
Seeing your graph would help get some better advice. You should have a table with values that you uses for the Value list and through the relationship they all auto populate.
It looks like you could use some rearranging of the relationships and the fields. It is so easy, but it can take a minute to understand the idea if you are not familiar with it.
You should have the drop-down actually running as a pop-up menu which is selected in the inspector. The popup field on the layout should be Equipment::equiptypeIDfk. The value list should be using Equipment Type::equiptypeIDpk and showing only values from the second field Equipment Type::Name field.
The other fields shown on the Equipment layout will be from the Equipment Type table. Because of the relationship only the correct data for that type is displayed.
You would no longer have Equipment::Terms and you would not need a script. Just add the Equipment Type::Terms field to the layout.
If you can post a development version of your file I can make the changes so you can better see how it should be arranged.
Someone recently had a situation that need the same solution and a sample file was posted. Possible to show another value than the foreign key in the foreign table?
Unless of course there is some really good reason for entering the data this way.
Thanks, I do have popup menu that can be manually selected I just wanted to setup the database when equipment type is selected the other items are automatically enter. Maybe what I have to do is put some of the information that I want automatically entered placed in the equipment table. That may help with what I need to do.
It is technically related and not entered, but yes you should have all of the data you want auto entered in a different table. This is the better way to do this.
I'm not exactly sure what you're describing above, but if a piece of equipment (or type) "has" something that sounds like an attribute relationship - either for the table itself or a child table, possibly.
You probably already know this, but in databases, when you say "Has", you may very well be talking about a child table or if it's not 1:M, then you may just be talking about the current table's attributes (customer name, customer address, etc.).
A CUSTOMER HAS ORDERS (1:M)
A TEACHER HAS STUDENTS (1:M)
Therefore, it sounds like each piece of equipment type could be linked to a child table with as much information (as many fields as needed) for that type. Due to the 1:M relationship, if more equipment types in the equipment_type child table (the many side) were applicable to the same piece of equipment, then you would just have more than 1 record in the "M" equipment_type table for each piece of equipment.
Equipment (1) Equipment Type table (M) - Single attribute shown for each matching row.
But to complicate matters a little, if each equipment_type could also be in multiple pieces of equipment (as shown above), then you have a M:M relationship and would need a M:M resolver table.
I would map this relationship out using an ERD tool and see if it makes sense...add some test data and play with it a bit.