Question

Preserving Global ID's from table to table

  • 18 October 2019
  • 7 replies
  • 143 views
B

Hi,

I have a couple of questions regarding migration of GlobalID’s from a source table (reader is a SQL creator) to be written into an existing ESRI Geodatabase (ArcSDE Geodb) table (destination).

 

1st question:

The destination table has the GlobalID field but all the values are zeros (see image below), does this seem correct?

 

2nd question:

Do I need to expose the GlobalID attribute in the workflow and then attempt to copy those GlobalID’s from the source table to the destination table (using a writer) in the workflow or should the “Preserve Global: Yes” parameters ensure that the incoming GlobalID’s will be preserved from the source table and embedded into the destination table?

 

I can run the FME script to run successfully however I cannot get the existing GlobalID’s from the source table to be written into the destination table, FYI each feature is linked by another attribute. I have tried copying using transformer and writers and I have also tried using the “Preserve GlobalID: Yes” by itself but the result is that the GlobalID's aren't being copied/written/preserved into the destination table. I am a junior when it comes to FME....

 

Sorry if there is not enough detail or if this is poorly described, please let me know if I need to elaborate…

 

Source table:

 

Destination table:

 

Thanks,

 

Bryce

7 replies

sigtill
Rank
Badge +21

Can you upoad the FME-log file?

The real SigTill
danielwebb
Rank
Badge +1

I'm having the same issue. The writer and reader are both SDE and the writer "Preserve GlobalID" parameter is set to Yes. But the output GlobalID all have "{00000000-0000-0000-0000-000000000000}".

 

According to this document, the GlobalID should be preserved in the output.

http://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/geodatabase/GEODATABASE_SDE_writer.htm?Highlight=globalid

 

The reason I want to preserve GlobalIDs is because I have a polygon with a related table that I want to use for updating another polygon layer with a related table with the same relationship class (GlobalID -> GUID). Maybe there's a better way to do this in FME, but it seemed like preserving GlobalIDs was my answer.

 

I'm using  FME 2020.2.1.0 (20201130 - Build 20806 - WIN64)

danielwebb
Rank
Badge +1

I'm having the same issue. The writer and reader are both SDE and the writer "Preserve GlobalID" parameter is set to Yes. But the output GlobalID all have "{00000000-0000-0000-0000-000000000000}".

 

According to this document, the GlobalID should be preserved in the output.

http://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/geodatabase/GEODATABASE_SDE_writer.htm?Highlight=globalid

 

The reason I want to preserve GlobalIDs is because I have a polygon with a related table that I want to use for updating another polygon layer with a related table with the same relationship class (GlobalID -> GUID). Maybe there's a better way to do this in FME, but it seemed like preserving GlobalIDs was my answer.

 

I'm using  FME 2020.2.1.0 (20201130 - Build 20806 - WIN64)

If it helps anyone, here is the error I get in FME.

 

Could not register GlobalID column 'GlobalID' in table 'DBO.sourcetable'. The error number from ArcObjects is: '-2147155969'. The error message from ArcObjects is: { [[Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name 'dbo.sourcetable' and the index name 'UUID_271'. The duplicate key value is (00000000-0000-0000-0000-000000000000).] [development.DBO.sourcetable]}

M
Badge +2

@danielwebb​ Preserve GlobalID : Yes should be working for you. On your writer feature type, make sure the GlobalID field is of type GlobalID. Does this feature class participate in a relationship or attachment or something?

I've attached a small example (FME 2021.2).

If the problem persists then please attached a small example, and also export the target geodb data model using the ArcCatalog to Export XML workspace Document (Schema only). If the data is confidential then perhaps contact you FME provider and open a support case.

danielwebb
Rank
Badge +1

@danielwebb​ Preserve GlobalID : Yes should be working for you. On your writer feature type, make sure the GlobalID field is of type GlobalID. Does this feature class participate in a relationship or attachment or something?

I've attached a small example (FME 2021.2).

If the problem persists then please attached a small example, and also export the target geodb data model using the ArcCatalog to Export XML workspace Document (Schema only). If the data is confidential then perhaps contact you FME provider and open a support case.

Yes, the feature class has a relationship class. Does that make a difference on whether the "Preserve GlobalID" parameter works?

M
Badge +2

Yes, the feature class has a relationship class. Does that make a difference on whether the "Preserve GlobalID" parameter works?

@danielwebb​ I think a relationship class might complicate things. Do you have a small example that you can attach?

danielwebb
Rank
Badge +1

Yes, the feature class has a relationship class. Does that make a difference on whether the "Preserve GlobalID" parameter works?

I can try putting together a testing example to share, but not sure when I'll have the time at the moment.

 

But I think I solved the issue at least for now.

 

Since a GUID can be copied and not unique, in ArcGIS Pro I set up an attribute rule on the source feature class to copy the GlobalID into a GUID field type called GlobalID_Origin. On the related layer and table being updated (the destination), I set up the relationship to be based on GlobalID_Origin --> GUID. In FME, the GlobalID_Origin from the source feature class passes the GlobalID_Origin to the destination feature class. And the source related table passes the GUID values to the source relationship table. This keeps the "original" GlobalID values, and the relationships of the source and destination are the same.

Reply


Community Stats

28,669
Posts
109,356
Replies
36,531
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.