topic Exporting/Copying stand alone table from one GDB to another converts GlobalID to text in ArcGIS Pro Questions

Exporting/Copying stand alone table from one GDB to another converts GlobalID to text

codethemap — Fri, 26 Sep 2025 09:36:00 GMT

Hi,

We want to copy branch versioned standalone tables from one GDB to another GDB with GlobalIDs preserved. When we use export tool for this activity, It converts GlobalIDs to text format. We've copied the feature classes using python script and GlobalIDs are preserved without any issue.

We've tried the following ways to copy the stand alone tables which are in relationship with feature classes-

1. TableToGeodatabase function in arcpy: GlobalID field is converted to Text type.

2. copy & paste: Gives error as Underlying DBMS error [[Microsoft][ODBC Driver 18 for SQL Server][SQL Server]The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name 'sde.R_featureclassA_featureclassB' and the index name 'UUID_199'. The duplicate key value is (00000000-0000-0000-0000-000000000000).]

'sde.R_featureclassA_featureclassB' is a Relationship class and the table is not related to any of the two feature classes in the relationship class.

3. Export table Geoprocessing tool: GlobalID field is converted to Text type.

Question: Can we export the standalone table without converting the GlobalID field to text type in GDB?

Re: Exporting/Copying stand alone table from one GDB to another converts GlobalID to text

Robert_LeClair — Fri, 26 Sep 2025 15:38:33 GMT

In the Export Table GP tool, if you click the Environments tab near the top there is a Geodatabase Advanced setting checkbox "Preserve Global IDs" that should accomplish what you want.

Re: Exporting/Copying stand alone table from one GDB to another converts GlobalID to text

codethemap — Mon, 29 Sep 2025 05:22:14 GMT

When using ExportTable with Preserve GlobalIDs, the GlobalID values are preserved, but they are stored as a Text field in the exported table. Once GlobalIDs are reenabled in the properties of the exported table, a proper GlobalID field is created and managed by ArcGIS. Here's the screenshot of the the fields.

Re: Exporting/Copying stand alone table from one GDB to another converts GlobalID to text

DustyJordan — Fri, 15 May 2026 03:37:25 GMT

Hi codethemap,

Did you ever find a work around for this?

I am running into the same issue. I had a Survey123 form with two related tables (repeats), which I am trying to export to a new geodatabase. Since it is converting my GlobalID fields to text I can no longer reconstruct the relationships between the main feature class and the two related tables.

As far as I know, GlobalID fields can't really be interacted with much, so it's not as simple a fix as just calculating the text GlobalIDs into the new GlobalID field. Not to mention creating a new GlobalID field autopopulates it with new IDs anyway.

Re: Exporting/Copying stand alone table from one GDB to another converts GlobalID to text

Robert_LeClair — Fri, 15 May 2026 14:55:20 GMT

Another workflow to consider, create a new target attribute table in the target geodatabase with a GlobalID field and set the geoprocessing environment Preserve GlobalIDs. The target GlobalID must have a unique attribute index as referenced here 003340: The target dataset must have a GlobalID field with a unique index in order to use the Preserve GlobalIDs geoprocessing environment setting.—ArcGIS Pro | Documentation

Re: Exporting/Copying stand alone table from one GDB to another converts GlobalID to text

DustyJordan — Sun, 17 May 2026 23:25:01 GMT

Hi Robert,

Thanks for the additional workflow suggestion.

Since this was a Survey123 dataset, what I ended up doing was going to ArcGIS Online and downloading the entire dataset in GDB format. Since I was also trying to convert this to a mobile geodatabase, I then just ran the conversion tool as outlined here: ArcGIS Blog - Migrating Data: Tools to migrate a personal geodatabase to a file or mobile geodatabase.

That seemed to have worked fine and preserved all the GlobalID and GUID fields as well as the relationships.

Thinking about it more afterwards, there were probably several workarounds for this. Another option I considered was 1) renaming the old GlobalID/GUID text fields, 2) creating new GUID and GlobalID fields in each child layer, 3) temporary join based on old key fields, 4) calculate new GlobalIDs into the new foreign key (GUID) fields. Seems like that probably would have worked, so figured I'd share in case anyone else finds that helpful.