Join Excel table to Feature Class by GlobalID

500
5
Jump to solution
08-24-2021 02:48 PM
Labels (2)
BrianOberdorf
New Contributor II

We have two corporate database system (GIS and Authority) that we store asset data in, that have become horribly mismatched. I have reconciled the attribute data from both in Excel, and now want to bring the new data back into GIS. The only consistent unique identifier is the GIS GlobalID which is in the spreadsheet. 

Due to the mess I used ArcPy to create a new geodatabase with new Feature Classes with standard field, domains and datasets. There are many slight discrepancies throughout the old GIS layers to the new layers.

I wanted to delete all the attributes except GlobalID from a old Feature Class, then paste these features into the new standardised geodatabase FeatureClass. I would then join via the GlobalID to the corrected Excel sheet to get the attribute values. There are a large number of layers and attributes.

However in ArcPro I cannot see the GlobalID of the original layer. I did export the original data from a corporate SDE database as a file geodatabase as I was concerned I would corrupt the original data.

Is there a method to expose the GlobalID of the features as an attribute field so I can use it as a join on copied data. The other options to join on are sometimes 80% completed, often way less meaning significant manual interrogation.

BrianOberdorf_2-1629841488282.png

 

BrianOberdorf_3-1629841523468.png

 

BrianOberdorf_4-1629841550276.png

 

 

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
JoeBorgione
MVP Esteemed Contributor

I hate to be the bearer of bad news, but global ids are controlled by the database  so they are volatile; if you copy/export a record from one database to another as you have, the new database overwrites the original global ids. Below is a screen capture of the same record in my enterprise (upper) and the exported feature in a fgdb.  Note the difference in Global ID values.

If you want Global IDs to persist, ad a text field to your gdb, and calculate it's value to equal the global id prior to exporting.  

JoeBorgione_0-1629845773740.png

 

 

That should just about do it....

View solution in original post

5 Replies
JoeBorgione
MVP Esteemed Contributor

I hate to be the bearer of bad news, but global ids are controlled by the database  so they are volatile; if you copy/export a record from one database to another as you have, the new database overwrites the original global ids. Below is a screen capture of the same record in my enterprise (upper) and the exported feature in a fgdb.  Note the difference in Global ID values.

If you want Global IDs to persist, ad a text field to your gdb, and calculate it's value to equal the global id prior to exporting.  

JoeBorgione_0-1629845773740.png

 

 

That should just about do it....
BrianOberdorf
New Contributor II

Thanks Joe, I thought there was an option to Preserve Global ID's but could figure out where it resided.

I appreciate your quick response.

0 Kudos
JoeBorgione
MVP Esteemed Contributor

There is now that you mention it.  Somewhere.  But I've never used it.  I don't like using global ids for any sort of join or relate because if their inherent volatility.

That should just about do it....
0 Kudos
JoeBorgione
MVP Esteemed Contributor
0 Kudos
MicZatorsky_AEC
Occasional Contributor II

I've found Global IDs to be stable, and reliable. And in my experience, the environment setting to  preserve GlobalIDs functions as intended.

I've used a hack to update a hosted feature layer using an XLSX with a GUID as the foreign key.  As you have found, the Add Join tool doesn't see the HFL GlobalID.   To expose it, I added text field GLOBALID_txt, to my HFL then populated that with the text of the GlobalId. 

This is an imperfect hack, not good for high-volume or real-time transactional systems sure.  But for simple applications, if new records are added you just run the calc field tool in Pro on demand and the join works.