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.

[IB1]

I can confirm that as well.  It still does not work.

Did you ever find a workaround for it? Or did you have to create all 180 of them manually?

[NathanHeick]

The only solution I see is learning ArcObjects or waiting for Esri to fix the bug.  Out of the 180, I have 19 relationship classes that use GUIDs that I have to create manually on a regular basis.  It also keeps our ETL process from being fully automated.

[AhmadAwada1]

Hi Nathan,

Seems like you worked with GUIDs and GlobalIDs well, are they reliable as PK/FK? Any limitations? DO you have a contact detail so that I can chat with u better?

[NathanHeick]

Hi Ahmad,

Because of the issue with the geoprocessing tool, we abandoned the idea of using GUIDs for relationship classes.  We ended up using integer IDs that were maintained by ArcObjects customizations.  The big issue was we could not rely on OBJECTIDs to be maintained during replication, so we were concerned our relationships would get broken.  So, we looked at GlobalIDs, but the issue with the geoprocessing tool made it hard to meet a requirement to drop and recreate the relationship classes on a weekly basis.  Later on, I believe we also noticed that feature-linked annotation requires you to use OBJECTIDs.  My memory may be wrong, but I believe that is correct.  You really have to test everything on a small scale before deciding to move forward with any approach.  I tried replication and editing to see how the software behaved in each case.  I noticed your comment below about GlobalIDs acting like OBJECTIDs.  We were also concerned about loading in data.  Custom integer IDs avoids that problem.

Thanks,

Nathan

[MarkReidy]

Still no work around?

[JoeJung]

Almost 2.5 years and this has not been fixed.

Has anyone figured out how to work around this?

[KenSam]

This issue is still not addressed in 10.3.  That's after close to 3 years when this msg was posted.  Bump up doesn't seem to work.  Need a megaphone!

[JoeJung]

I can't seem to "follow the status" of the bug any more, I just get stuck in an endless loop of signing in to my esri global account.

Seriously, this needs to be addressed.  Every month I come across a situation where this would save me a tremendous amount of time.

[KyleMattison]

I had to search the number manually to actually find it. You can see the status here: NIM082537

It actually looks like there is an even older bug report about the same issue for ArcGIS 10.0: NIM072002

[BillDaigle]

Seriously, there is still no fix for this???