GlobalID or "user managed" GUID in relationship classes in a replicated database

11-01-2012 12:54 AM
by Anonymous User
Not applicable
Original User: tomlind

We are designing a geodatabase (using 10.1) with extensive use of relationship classes, and will be using replication for disconnected editing. Replication makes use of the GlobalID data type to track changes and when new objects are created the field is automatically populated with a GUID. This may be attractive to simplify the editing process and caused us initially to use the GlobalID as the key in our relationship classes.

However, a couple of years ago I read articles (which I can't locate any more) clearly advising against using GlobalID as a persistent identifier (e.g in relationships), since it was only meant as a way to support replication in the geodatabase. I am aware that many tools (like append, export data etc) don't preserve GlobalIDs, and some do (copy/paste, XML workspace import/export), which is a strong argument against using GlobalID.

So, we are planning to change our design and use GUID for our identifiers and manage them ourself, and only add GlobalIDs to support replication. The only drawback we see now is that we have to generate the GUIDs programatically when editing, which I don't think is a big deal. Our initial tests with replication (checkin/check out) seems to work in the same way as when using the GlobalID as identifiers.

So, I would appreciate any views or experience on this issue before actually redesigning the geodatase. Are we missing something important? Has something in 10.1 made it more acceptable to use GlobalIDs in relationship classes?

I have a feeling that the advice is not equally strong against GlobalIDs nowadays, and see several examples where it is used, and advise on how to work around the drawbacks like

Any tips on generating or managing GUIDs would be helpful!

0 Kudos
0 Replies