Problems with GLOBALIDs, GUIDs, and the Create Relationship Class GP Tool

[NathanHeick]

I am trying to create relationship classes using the geoprocessing tool Create Relationship Class in Python and in ArcCatalog.  I am using an origin primary key that is a GLOBALID and an origin foreign key that is GUID.  The error I receive in Python is:

Failed to execute. Parameters are not valid.
ERROR 000800: The value is not a member of GLOBALID.
Failed to execute (CreateRelationshipClass).

In ArcCatalog, when accessing the GP tool from ArcToolbox, once I select the origina primary key as a GLOBALID, it will only let me choose from the GLOBALID in the destination table as valid foreign keys.

To me, it seems like the GP tool is too restrictive and only lets you make relationship classes between GLOBALIDs and GLOBALIDs, not GLOBALIDs and GUIDs.

If I choose New -> Relationship Class in ArcCatalog, it allows me to choose from the GLOBALID field and the GUID field in the destination table.  It allows relationships between GLOBALIDs and GUIDs.

Does anyone have a workaround for this or an explanation?  I have to drop and recreate 180 relationship classes in an automated fashion and I would prefer to use Python.

[JoeBorgione]

The only thing I use Global IDs for is database replication.  For relationships, I use a field called... (wait for it) JoinItem or something along those lines.  Make a Long Int and calc it to equal the feature's OID.  That way if you move data to a different db the joinitem remains static and unique.

[BillDaigle]

I thought about that too. But I’m trying to set up a cross-platform (ArcMap and Web) editing work flow. I don’t want the users to maintain the key fields.

[JoeBorgione]

Yep- if it weren't for users, our jobs would be easier. If they are editing on a  SDE db, you could write a trigger to update the joinid field when a record is added.  Just a thought....

[BillDaigle]

It's a good thought.  I'm trying my best to stick with geodatabase functionality so that I run into problems down the road if we decide to use versioning or replication.  Looks like I'm stuck with creating relationship classes by hand for now.

[FredericWalter]

I think i finally found a workaround for ArcGIS 10.2.2

  1. Create the origin table / featureclass with the globalid

  2. Create the destination table / featureclass with GUID field as a foreign key without the globalid

  3. Create the relationship class

  4. Add the globalid to the destination table / featureclass

[AhmadAwada1]

Hi frederik, your workaround seems good, but what about performance during joins? How is global id/guid performance when table sizes are hundres of thousands? Also did u find any limitation with GlobalIDs? I noticed that globalids are changed during append or loading operations. What are their advantage over objectids then?

[FredericWalter]

Hi Ahmad,

Actually, it works like a charm. We choose to base our relationship over globalid / guid, because we work with distributed geodatabase and it was the best (only ?) way to avoid conflict between multiple replicas when they were imported into the master geodatabase.

Performance stay good, but we don't have any large tables / feature classes (thousands of record). I think, it will depends on the underlying RDBMS. We use PostgreSQL.

We planed to upgrade to ArcGIS 10.5.1 this year.

[AhmadAwada1]

Dear frederik,

First of all thank you for the reply.

Sometimes u need to flush a feature class in ur db and reload from an fgdb for ex, the globalid will change and the relation will break. U might tell me do copy paste but it is too common to have the scenario am talking about. What do u say?

Get Outlook for iOS<https://aka.ms/o0ukef>

[FredericWalter]

Hi,

We use the CreateReplica tool from the distributed geodatabase toolbox to create the fgdb from the postgresql db. With a fgdb, we have to create a check_out replica. To import the fgdb to the postgresql db, we use the synchronize changes tool. With those tools, the global is are not changed.

[FelixPertziger]

Great workaround! Thank you very much!