One-to-many join — Editing duplicate input table rows

[Bud]

We can use the Add Join (Data Management) tool to make a one-to-many join. The resulting attribute table will have duplicate input table rows.

From the docs:

Questions:

1. Does Esri recommend editing the duplicate input table rows?
2. Are there any known issues?
3. Is the behavior demonstrated in the below example/GIF expected?

Example:

Source data:

Joined:

Editing:

Notes:

1. I'm aware that's an unusual usage pattern. But if users can do it, then they will do it.
2. The duplicate rows don't auto-refresh. Users might find that confusing.
3. Selecting one duplicate row will automatically select all of the corresponding duplicates. It took me a while to get used to that behavior.

[JonathanNeal · Accepted solution]

@Bud Yeah perfect example of behavior a 1:m join does that is confusing to users. Currently this is how it works Last in wins.

Details:
A join is a construct of a layer.  A layer references the data on disk.  So in the above case, 1 record is referenced two times by the TableView since it is a 1:m join.  So when editing the data on the input layer that is 1:m, each change is written to disk, but the last one is what is shown when you refresh.

Thanks for bringing this up.  Adding the above explination will be good for our documentation.

[Bud]

Thanks.

[JonathanNeal]

@Bud If you want to edit the data as shown above.  The data needs a place on disk to be updated at.  So, after the 1:m join layer, using Copy Features or Export Features is needed to avoid last in behavior.