Creating relationship classes for repeats on service

[KennethLindhardt1]

Hi, I'm sorry, I can't understand this.

I have a 1:M relationship class.

when a relationship class is created I have an origin table with a Join ID and a destination table with multiple Join ID's that matches the Origin table.

When a relationship is created, I would think that Table A should have a field in Table B that matches.

GUID: As far I understand, this is a unique identifier, meaning I would not expect that my "many" table could have identical GUID attributes in the same table.

Also it's not that easy to find the relationship between two tables.

There must be something stupid I can't figure out here 😄 but I can't make sense of it.

I have a number going through all my different datasets, and therefore I'm able to create a perfect relationship class, but since this is only a 10-character field, it will never be able to get calculated into the GUID, and therefore no repeats from a feature service

Thanks.

[DougBrowning]

The built in way 123 works is it creates a field called parentglobalid (which is a GUID) in the repeat and populates that with the globalid of the parent.  They must be named that way.  You can add additional and manage your own (as I do) but you must keep the built in ones.  GlobalID is actually not a great choice as if you export to say SDE later all of this breaks.  That is why I add a second one I manage.

Hope that makes sense.

[KennethLindhardt1]

Thank you Doug, for your answer. Unfortunately Am still a bit confused about maintaining the relationship between related features. Du I understand the description in the blog's wrong: Repeats will only be created if the relationship uses a GUID field (that's what I'm getting out of it anyway)

The global ID is created when you activate sync, but I've already creating the relationship prior to sharing. In my case I use a !buildingID! + !Date! In a text field. Pro and online maintain that relationship, if I share it. If I manually create a GUID field I can't see how that field is jæused as the join field, which is how I understand that Survey123 works.

I feel like having something going very wrong in my understanding of this.

[KennethLindhardt1]

Arh got it, it does create a bit of preparation to get to work.

This helped me to understand it a bit more: https://youtu.be/n5ytk52KlAk?si=suVHhfAXBhtZUeB1&t=2713

As you said (and what I did) @DougBrowning  A global ID is created from the GP tool on the origin layer, a on the destination layer, I'm creating a GUID field "parentglobalid".

(Now to the bulky part, I don't know if this could be done smarter)

I'm using my own join ID, to create a Join from the Dist to the Origin layer, then I calculate my parentglobalid field from the GlobalID field. 

This means that my Distination layer have identical parentglobalid attributes, and I can create a 1 to many relationship class.

another thing that seems important, is the label that needs to be identical.

Now I get repeats in my Survey123.

Since I thought the Joining and calculating was a bit bulky, I tested if I could still use my own simple ID (against the blogs I've read, except one) but still making sure that the label is identical in the relationshipclass.

//edited from here to match real facts:

That will not work!

So my big mistake was wrong Labels, and then I need to create the GUID.

[DougBrowning]

yea you can have 2 relates but you must have the the parentglobalid for the built in way or 123 will get mad.  That is why I run both.  

My big write up in this post may help   https://community.esri.com/t5/arcgis-survey123-questions/mapping-with-survey123-within-a-polygon-or-... 

[KennethLindhardt1]

Arg, thank you for explaining. Survey123, is actually getting mad 😄 but first when you want to publish.

Oh man, this is will be a pain to maintain with monthly data updates, hopefully it will be awesome at the end.

Thank you I will update my post, that it will not work ignoring globalparentid/GlobalID