Disallow 1:M join layers as GP inputs instead of producing unexpected results

Bud

The Add Join docs say:

Because many geoprocessing tools do not support data with duplicate object IDs and processing such data can produce unexpected results, it is recommended that you first copy the joined layer to a new feature class using the Export Features tool. Then use the new feature class as input to other geoprocessing tools.

If 1:M join layers are not an acceptable input, then an error should be thrown rather than accepting invalid data and producing incorrect results.

Can geoprocessing tools be enhanced so that they disallow 1:M join layers, where applicable?

DrewFlater · ‎05-22-2024

@Bud the condition with duplicate OIDs caused by a 1:M join cannot be known until the data is completely read, so this is not possible to "disallow" such layers from being used as input. We have found that some tools error under this condition, while others use the first record in the set of duplicate OIDs, while others do other things. All of these specific behaviors based on different tool implementations cannot be explained in full detail in a documentation topic like you highlighted from Add Join, thus the generic "can produce unexpected results".

We have internal development enhancement issues logged to support dynamically generating unique OIDs for the case of 1:M joins, which will work around any limitations there may be for geoprocessing tool algorithms that require unique OIDs. This idea in the current state is not actionable, but if you want to change the idea or enter a new idea for some tools that you have used to support 1:M join layers as input without duplicating the OIDs, we can make a match to our internal development issue.

RTPL_AU · ‎07-14-2024

@Bud Rephrase your idea as: Support dynamically generating unique OIDs for the case of 1:M joins, to work around any limitations there may be for geoprocessing tool algorithms that require unique OIDs. 🤣

Bud · ‎07-14-2024