Collector: 1:M related table without having to re-type PK value in FK field

[TobiasFimpel1]

When I insert a record into a related table via Collector my foreign key value is not auto-populated, as this blog​ and the comments suggests. Any suggestions for where to start troubleshooting this, or how to configure this correctly?

The relationship class is based on a GlobalID field and a field of type GUID. The above referenced blog states "foreign key should be set to a new, unique GUID field." What is meant by a unique GUID field? In a 1:M relationship the foreign key field cannot be constrained to unique values, or else it would be a 1:1 relationship.

My setup: ArcGIS Server 10.3, Geodatabase 10.3 Oracle 11g, web map with 1 versioned point feature class, a related table, and attachments. Pretty much as simple as it can get. Thank you!

[ToddBlanchette]

Hi Tobias,

I'm not sure I fully understand the issue you're having but I see the following:

1. The page you linked to is not telling you to set your foreign key to a unique GUID, it says to build your relationships off the parent feature's GUID so that you'll always have a guaranteed unique identifier for the 1 in the 1:M relationship (avoiding a M:M error, which isn't supported).  From the page:

"We recommend that you create relationships using the GlobalID field on your layer so that primary key of the relationship (your parent hydrant feature) is guaranteed to be unique when establishing a connection to a new inspection record."

2. I can't say why your foreign key isn't populating as I don't know what your collection process is.  When you're creating a new table entry, are you first clicking on it's related feature and then creating a new associated relationship entry in the related table?  Is it possible for you to screenshot this process?

[TobiasFimpel1]

Thanks for your reply Todd. Sorry I never got you any screenshots so far, but what you describe in #2 is the workflow I'm following - as far as I know that's the only way to edit a related table in collector.

With some feature services and feature classes it works as expected and with some it doesn't. I'll have to spend some more time troubleshooting to figure out what is required for 1:M relationships to behave correctly. I believe there isn't much in terms of documentation and known issues.

[ToddBlanchette]

Thanks for the reply Tobias.  If the issue isn't with the workflow, then I would be looking at the actual relationship class itself to see if there were any errors with the properties made during creation.  Especially the case if it works with some feature classes and not others.