Select to view content in your preferred language

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

1393
3
Jump to solution
01-23-2023 07:25 AM
Bud
by
Esteemed Contributor

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:

Bud_0-1674484866543.png

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:

Bud_3-1674485521861.png

Joined:

Bud_5-1674485702251.png

Editing:

One-to-many join - editing duplicate Input Table rows.gif

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.
0 Kudos
1 Solution

Accepted Solutions
JonathanNeal
Esri Contributor

@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.

View solution in original post

3 Replies
JonathanNeal
Esri Contributor

@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
by
Esteemed Contributor

Thanks.

0 Kudos
JonathanNeal
Esri Contributor

@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.