nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Encontre mais publicações marcadas com

Accepted answers

All comments

NeilEtheridge

NIM082537 is fixed at 10.6.1. Also fixed in ArcGIS 10.2.1 for (Desktop, Engine, Server) Utilities and Telecom Update 9 Patch

FelixPertziger

Great workaround! Thank you very much!

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 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.

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

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?

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?

deleted-user-RvrkOqzR6NTy

I can confirm as Philip says that it is indeed fixed in ArcGIS Pro Desktop

PhilipMarley

Looks like the bug is fixed in ArcPro. I got the same error in Desktop, ran in Pro and it worked!

CallumSmith

The problem still persists in 10.4.1 but Fredric's workaround above works for me! Cheers

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

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

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

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

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

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

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.

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

Almost 2.5 years and this has not been fixed.

Has anyone figured out how to work around this?

MarkReidy

Still no work around?

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.

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

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

IB1

The bug that was logged for this is NIM082537. You can follow the status of it here.

Thanks! You the man. I'll shut up now.

Hopefully it gets fixed soon.

BTW- the Version found should be 10.0 and 10.1, not just 10.1

jskinner

The bug that was logged for this is NIM082537. You can follow the status of it here.

IB1

Bump, bump ... bump it up.

IB1

Bump, bump ... bump it up.

IB1

Bump it up

IB1

Bump it up

IB1

Any word on this ESRI?

Can't this be an easy fix?

I really need this to work with Python.

I'm using 10.0 and am having the same issue.

NathanHeick

I followed up with Esri Technical Support on this issue. They reported it as a bug and said that it won't be corrected until a later release of ArcGIS 10.1.

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.