Field Calculation Between Related Tables - ArcGIS Pro

[SuzyFer]

I am attempting to pull some information from a related table into my main feature class by using the field calculator but so far everything I have found online has failed.

I believe this should be fairly simple with some Arcade expression.

I have two feature classes with tree canopy information, with a relate between the two tables (ie. Relate1). Canopy1 is the main feature class I want to work with but I have some specific canopy calculations in feature class Canopy2 that I would like to populate in one of the Canopy1 fields.

Would anyone be able help with the Arcade expression for this please?

[Roger_Schulz]

A few screenshots of the data structure might be useful to you to understand where you want the field calculation to go and what you have in mind for your solution. 

Have you tried to run a full join instead of running it as a Related table and then calculate? 

You might also want to try adding an attribute rule to run the calculation to Canopy 1 fields when there is a modification or update. 

Hope this helps

[jcarlson]

It shouldn't be too hard. In Arcade, you can access related tables with the function FeatureSetByRelationshipName, and the result of that function is already filtered to the related records. You'd need some way to filter the result to a single feature. Here's me just grabbing the first record in a related table.

var can2 = FeatureSetByRelationshipName($feature, 'Relate1', ['the_field_you_want'], false)

// get the first feature
var can2_feat = First(can2)

// return value
return can2_feat['the_field_you_want']

Just be sure you get the relationship name right in that first line, and ask for whatever fields you need to do your work. Assuming it's just pulling a single value, though, it's a pretty straightforward operation.

[Bud]

1. What kind of geodatabase? For example, Oracle 18c 10.7.1 enterprise geodatabase.
2. What version of ArcGIS Pro?
3. Related: 1:M Join to Pull feature with Specific Attribute information
4. Can you confirm that a relate is indeed needed due to the underlying data structure being one-to-many? Or is the data structure one-to-one?
5. Have you ruled out using a one-to-many join?
6. What does the data look like?