1 of 1 people found this helpful
When you match by name, you have to have a way to deal with duplicate names.
That said, please describe what exactly you are attempting to do? (I can come up with several interpretations of what you are asking here. )
Thank you for answering my post.
I have a database which is student IDs, phone #s, email addresses, etc. Some of the records need to be corrected as time goes by, and some empty fields need to be filled in.
For example, if I am given an updated email address for a student, I want one of my tables to be the "intake" table where I change the old record to the new, correct email. How can I make this field on the intake table the source field and the matching fields (for that student) on the other tables the target? So John Doe's new email on the intake table changes John Doe's email on all the tables related to it.
Same thing goes for empty fields. If I'm issuing equipment with serial numbers to students, I want the intake table to be the source and the other tables the target.
BTW, there are no duplicate names on any of the tables.
It's possible that I'm not getting your example. So in general, when developing a database, I try to keep only one copy of a key piece of data, like an e-mail address or name. So this would only be in one table.
When you create a layout, based on TO CU_SR_CLASS_ROS... and you want to display the name of the student or the e-mail, you would put the field from Student Contactsh on the layout.
In general, connect Table occurences by record ID, and not name. While you may not have a duplicate name in the current database, there is more then on John Smith in the world, you never know when two of them will show up ant the same time.
So short answer to your question about updating related data. There are two options. The first is make one an unstored calculation that gets the data from the other table. The second is run a script that does a set field script step.
Instead of an intake table, the simplest solution is to simply set up a system where the original record is found and updated.
But sometimes when updating data, it makes sense to do it on a transactional basis where the current version of the record is not modified until the user has finished entering data and the inputs have completed any validation checks built. That might be why you want an "intake table".
I would instead use a set of global fields for this purpose. You can set up a system where a user enters or selects a name from a value list formatted global field, a script then finds the matching record or records and loads a set of global fields with the data from that found record. When a user clicks "save" or "submit", that button checks to be sure the data is complete and valid, then transfers the data from the global fields back to the found record to update it.
Does that sound like what you want to do here?