I'm trying to create a one-to-many relationship class between a Feature Class and a blank Table that are both within the same GDB. The feature class is of the point variety and has GlobalIDs assigned. The table has the fields and domains all set up and is ready to be populated. It also has GlobalIDs assigned and a GUID field (Key) set up. Both datasets have a common identifier between them, the ID of the feature, which could be used in a local relate instance. Once this relationship class has been established, I will be uploading to AGOL and building field apps around it.
I have done this before with another feature class, and was able to recall all table entries of a feature by highlighting the feature, then on the menu navigating Feature Layer -> Data -> Relationship -> Related Data, which would bring up the option of choosing which table I would like to view the attributes from. I select the table from Related Data, and it opens with all related entries. All of this is in AGOL and works fantastically. This relationship class was formed on the GDB level and uploaded to AGOL with zero issues.
I have tried every configuration possible of origin and destination tables and keys (using both ID and GlobalID/GUID in differing configurations) in creating this particular Relationship Class, and when I highlight the feature (with the feature class highlighted), there is no option to open any related data using the above method. HOWEVER, if I highlight the table and then select a record, I have the option of opening the feature class under Related Data. It's almost like it's working backwards.
Hopefully it is something simple keeping this from happening. I'm still new to ArcGIS Pro, but I feel I have enough of a grasp to be genuinely puzzled by this. Thanks for reading this far, and please let me know if I need to elaborate on anything.
When you create a relationship class, the best way is to go Feature Class GlobalID → Table GUID. You could set up the relationship based on the shared ID, but it's not as reliable.
In order for the GlobalID → GUID relationship class to actually have any relationships in it, you'll need to fill in the GUID field with the proper value if it's not already in place. You could do that with a field calculation based on the shared ID.
How do I set up the calculation for the GUID to take place? I assume that with every record entry, this would need to happen automatically.
The strange thing about this is that with my previous successful pass on doing this, the key fields remain unpopulated but the relationships are rock solid during recall. Strange.
Run a field calculation on the table to populate the GUID field, something like this:
var fs = FeatureSetByName($datastore, 'parent feature class name', ['GlobalID'], false) var feat_id = $feature['id_field'] // this would be the shared feature id between the two layers // return the single feature based on shared id field var parent_feat = First(Filter(fs, 'id_field = @feat_id')) // get the globalid from the parent feature return parent_feat['GlobalID']
As for the "automatically" part, that really depends. If entries are made to this table via something like Survey123, yes. But if you're just appending items to the table, there's really nothing there to tell it to go looking for a GUID, unless your layers are stored in a database that allows attribute rules.
How are you planning to edit / add to the two layers?
Thank you for the code. I'm hoping I don't have to go that far, as I've done this before. Fingers crossed.
I'm planning on creating a Survey123 form that outputs to the Table.
As an experiment, I copied the GlobalID from one of the features and placed it in the GUID of a new record in the table. With the relationship class formed, I am able to call the feature as related data from the table, but I cannot call the record as related data from the feature... I hope I worded that correctly. It should be the other way around.
For anyone in the same boat, this is how the problem got solved: I contacted ESRI tech support and they found that exporting a new feature class from the one giving me problems and using that new class did the trick. I also tried copying a good feature class from one GDB to another also worked. I guess there was some obscure technical glitch that had to be scraped off by using a different feature class.
In short, using a copy of the original data saved the day.