Select to view content in your preferred language

Indicate what caused type of join to be used (1:1 vs 1:M)

233
2
4 weeks ago
Status: Open
Labels (1)
Bud
by
Notable Contributor

Edited.

It is my understanding that there are two join scenarios in Pro (via Add Join):

  1. Forced one-to-first join (1:1), even if underlying data is one-to-many.
    1. Possible reasons:
      1. At least one of the tables doesn’t have an ObjectId.
      2. Or, the tables are not in same workspace.
      3. Or, at least one of the tables isn’t registered with the geodatabase (not documented)
      4. Or, the user specified the join type in Add Join in Pro 3.3.0+.
  2. A one-to-many (1:M) join is allowed, but the data might not actually have any 1:M records.
    1. Possible reasons:
      1. The tables have ObjectIDs, are in the same workspace, and are registered with the geodatabase.
      2. Or, the user specified the join type in Add Join in Pro 3.3.0+
        2.a.i above would also need to apply.

Idea:

In the Catalog layer properties, indicate what caused the type of join to be used since it isn’t always obvious, especially when using a map made by someone else. For example, Pro 3.2.2 Will Not Do a 1:M Join

 

2 Comments
Bud
by

Note:

The “Duplicate rows” warning at the bottom of the attribute table is only displayed if duplicate records are present in the data. This warning doesn’t necessarily indicate if the join type is #1 vs #2. It could be #2, but no 1:M records exist in the data, so the message wouldn’t be displayed in that case. So we can’t rely on that message to indicate if the join is #1 or #2.

With that said, the Layer Properties —> Joins tab does indicate the type of join in the cardinality section. 

Bud_0-1715883586077.png

 

Bud
by

It would also help if the Add Join geoprocessing tool could indicate why a 1:1 join is being forced, etc.

Bud_0-1715914114560.png