Related Tables for Offline Data Collection

Jump to solution
10-14-2015 07:54 AM
Occasional Contributor II

I have a question regarding creating relationship class for offline data collection. According to this Esri blog,  "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."

And then in this ArcGIS Server documentation, it reads, "elationship classes and attachments must use a Global ID primary key."

Also, when I consulted with Esri Support analyst for Collector sync issue I was having, he said the relationship class in my database that did not use Global ID as primary key wasn't causing the issue.

So I am confused whether it's a requirement or a recommendation to use Global ID as primary key, when creating relationship class for offline data collection.

Tags (2)
1 Solution

Accepted Solutions
Esri Regular Contributor

It is a recommendation to use GlobalID instead of a requirement. If you don't use GlobalID, you need to manage those keys by yourself and avoid orphan child.

View solution in original post

10 Replies
Esri Regular Contributor

It is a recommendation to use GlobalID instead of a requirement. If you don't use GlobalID, you need to manage those keys by yourself and avoid orphan child.

New Contributor

Hi everybody,


Sorry to just enter in scene where the solution seem to have been found.


I have the same problem, can't go offline with my map. All my features have an indec, and GlobalID field, and my relatinships are based on it. also, when i Check my Supports ApplyEdits With Global Ids it's set to  true, can you help please?

0 Kudos
Occasional Contributor

Actually, here is  a very important use case that does not involve globalIDs:

Imagine that the parent layer in a hosted service contains points of addresses. These addresses originate from a non-spatial business system within your organization. As expected the system generates unique integers for each address. Meanwhile, the ArcGIS child layer exists to track visits to addresses with Collector. Certain fields contain information you would like to bring back to your business system.

By using an integer field (AddressID) for the relationship,  the transfering and synchronizing with the external database is simpler. Where as trying to force globalIDs into your bussiness system would just complicate the workflow.

One caveat is that you may want to prevent null values for the related field in the parent layer. That is unless the workflow allows users to create orphaned features in the child layer.

Occasional Contributor II

That makes sense that esri recommends you use globalID as the primary key because it is automatically generated so you don't have to maintain it.  However, is there another solution for an automatically generated key?  Using globalID creates problems if you ever want to export the data to a different geodatabase.  I believe the globalIDs will be regenerated thereby destroying your relationship.  Is there another way to create a primary key that is automatically generated but doesn't change if the database is exported?

MVP Honored Contributor

I agree I do not use GlobalIDs at all mostly because of the exporting.  Pro does now have an option to maintain GlobalIDs on export but that is new. 

But the biggest reason is how Arc manages relationship keys. 

I believe most of us think there are 2 options for relationships classes - managed and unmanaged. 

Managed means if I delete a parent record all children are deleted.

Unmanaged means if i delete a parent then do nothing - right?  Wrong!  

   Arc actually goes and turns all the child keys to NULL!!  (no one I asked knew this).

So if you say need to reload your parents due to a calculation issue or something (happens to me a lot).  I first change all my parent keys to the word delete.  Then save (and in my case replicate).  Then delete the parents.  That way when it goes to look for the children it does not find any and nothing gets messed up.  Then I can just replace my parents and all good in the hood.

If you ever had to reload data and you are using GlobalIDs you are dead in the water.  You can not edit or replace any GlobalIDs.  Maybe you can as a GUID I guess - I would have to think about it.  We export to things like Excel and using a non globalid just seems to work better.

Also there is no way to generate them if they get nulled out or anything.  We use keys that we can recreate at any time with some info.  So lets say Division_Office_Plot_Year or something like that with a meaning that can be understood.

Hope that helps.  I have 60+ relationships classes so I deal with this a lot.

New Contributor III

Alright...Let me explain further.  you need a unique identifier as a primary key.  I'm not even going to use ObjectID because those can change based on some data management workflows that will recreate a new ObjectID value..  We have a 'UID' field on all of our features that we've used as a unique Identifier, but completely manually entered that does not restrict "uniqueness".  Since GlobalID is mandatory in some cases according to ESRI, that is the second auto created ID field used in the feature class and therefore the max of 2 auto-generated fields are now maxed out.  my answer to this is to create a rule on the uid and using a SQL sequence, and a rule, I can have an auto-incrementing field.  This all works fine in Pro, but the service skips a number on every inserted feature or table record (another case that I am working with ESRI about).  This is all well and good if you are working only in Pro or ArcMap, but we are using feature layers in services to supply an editable map in Collector for field collection/sign management. If the rule is not acting up for creating a UID on the fly, it does not insert a value until you commit the new record/feature through the service so the value is empty until then.  These relationships (in relationship class) between a pole and it's signs are not something that can or should be done in Collector by a tech in the field manually!  The GlobalID and a matching GUID field in the related table/FC takes care of the issue. 

New Contributor III

In a composite relationship, you can set up messaging forward and backwards or both directions will delete the child if the parent record is deleted.  See "message functionality" here:

"Message notification direction

As previously discussed, when you delete an origin object in a composite relationship, related destination objects are automatically deleted."

"When setting the direction for composite relationships, keep in mind that when the origin object in a composite relationship is deleted, all related objects in the destination are automatically deleted. This happens regardless of whether messaging is set to Forward, Backward, Both, or None."

0 Kudos
New Contributor III

ESRI has a limit of 2 (max) system-maintained ID fields in a table of FC.  The ObjectID field will be regenerated if you "copy" a FC to another location, so never use ObjectID in a relationship class, but I am under the impression that a copy will not affect the GlobalID if already populated, it copies the same value to the new FC while the ObjectID gets a new value.   I could be wrong, but I was told that by someone and not tested it myself yet.  I believe that is one of the advantages to a relationship class maintaining the GlobalIDs throughout your processes. I make reference to this in another comment on this thread, but I use a sequence triggered by a rule to create a third (or fourth or fifth...), unique identifier field.

0 Kudos
New Contributor

I'm confused on this as well, because like the OP I found those statements in the documentation, and I have several relationship classes using GlobalIDs, however, I am unable to take my map offline in Collector because "supportsApplyEditsWithGlobalIDs" property is set to false. I found this tech page which suggests you CAN NOT have a GlobalID-based relationship class and use it offline with Collector... (and yes I DO have unique attribute indexes as the "workaround" suggests)

Problem: The Supports ApplyEdits With Global Ids parameter is set to false 

Has anybody figured out how to accomplish this? I need the relationships to be GlobalID-based because it would be such a pain to set up a back-end way of managing GUID fields for all our Collector data!

0 Kudos