Is it possible to have multiple feature classes participate via relationship classes with the same destination table? So multiple point feature classes representing different assets like Utility Poles, Street Light Poles, etc each having their own 1:M relationship with a shared table of road signs (each point in the feature classes can have one or more sign records related to them)? When I try and add a record in the related sign table through any of the feature classes, the submission fails. The relationships are all GlobalID to GUID.
I am having an issue with saving records to a related table that is the destination for several relationship classes with several different feature classes.
When I attempt to save a record to the related table for any of the features, the application either gets stuck on submitting or throws up an "Unable to submit Service code error 1000".
All the documentation that I can find regarding relationship classes seem to indicate that having multiple feature classes participating in their own relationship class with the same table is possible as long as the relationship type is Simple and not Composite. All of the FC's and tables are in the same FGDB uploaded to AGOL as a hosted feature layer. The relationship between all the feature classes and the sign table is 1:M.
I am attempting a City-wide inventory of street signs, but I would like to keep all the individual sign records within one table which then relates to multiple feature classes that include the point location and data for the physical structures each sign is attached to, so things like utility poles, street lights, channel posts, etc.
I started off by combining the different types of structures into a single point feature class (stripped of any structure-specific attribution) and then had that FC related to multiple tables: 1 table for the signs, and a table for each type of structure (so a table for the attributes specifically related to utility poles, another for the street lights, etc). This works well except I want to be able to symbolize the points for the different structures based on fields in their specific related attribute tables; the easiest way I can think to do that is to instead keep them as their separate feature classes with all their unique attribution and just relate those to the signs table.
Is this possible, or is there some technical reason why having multiple feature classes relating to the same table would be problematic? All the relationship classes use the GlobalID value from the feature classes and a ParentGuid field within the signs table to function.
This is another post that seems to indicate this setup works (though there was an issue with it working in an offline environment which would not affect my case as I am working off of a tablet with cellular connection) https://community.esri.com/t5/data-management-questions/can-a-table-belong-to-multiple-relationship/...
As a note: I am similarly unable to submit related table records with this setup through the editing widget within a WAB app.
Any assistance or guidance on this issue would be GREATLY appreciated.