Will there be a problem if two difference ArcSDE databases have the same GlobalIDs? One is a copy of the other, for testing purposes.

376
5
Jump to solution
04-10-2017 02:48 PM
Highlighted
MVP Esteemed Contributor

We are testing on a new (remote vs local) server, using various (SQL) ArcSDE versions, etc.  Since we want the testing to be fair, I'm creating new databases and then dong a copy-paste of the database.

The newly pasted data needs to be "registered as version".  Since the globalIDs came over intact from the source database, will there be any issues if I leave them as is (i.e. the same values), or do I need to destroy the duplicate values and create new ones?

I thought I saw a question about how to replace globalids in the last couple weeks, but couldn't see a reason why....until now.  (and can't find that thread right now).

Reply
0 Kudos
1 Solution

Accepted Solutions
Highlighted
MVP Esteemed Contributor

How do you plan to use the two databases?  The only thing I use GUIDs for is replication.  If you use them as keys in a relationship somehow, I suppose you could have an issue somewhere down the line if you update a related feature or record with values based on one of the test gbds, when you meant to update based on the other.

The only way I know how to replace global ids is to remove them and re-add them.

Let's see what Derek Law has to say...

dlaw-esristaff

View solution in original post

5 Replies
Highlighted
MVP Esteemed Contributor

How do you plan to use the two databases?  The only thing I use GUIDs for is replication.  If you use them as keys in a relationship somehow, I suppose you could have an issue somewhere down the line if you update a related feature or record with values based on one of the test gbds, when you meant to update based on the other.

The only way I know how to replace global ids is to remove them and re-add them.

Let's see what Derek Law has to say...

dlaw-esristaff

View solution in original post

Highlighted
MVP Esteemed Contributor

Thanks Joe,

It's really just for testing, and they will be deleted once we are done testing in a couple weeks.  At that time (or soon after hopefully) we'll do a clean backup and restore from our current master (SDE 10.2.1, SQL 2008) to our new master (SDE 10.3/10.5, SQL 2014). 

We're testing the different SDE, SQL version, and check-out vs. two-way replicate, etc.  The remote server seems to slow a 18 sec draw process (local) to about 3.5 min draw from the remote SQL, but I'm trying to make sure I'm giving all options a shot before I try to push for a local SQL install of our master topo/version/replicated database which is edited locally most days. 

That's just drawing the layers....editing and the reconcile/post is still being tested.  Editing a check-out version is great (local), but the reconcile/post and pushing back to the default has me a bit concerned....but don't have any hard numbers on it yet.  Again, trying to give all our options a fair shake before reporting back...and even then we may lose out and just have to twiddle our thumbs a lot. 

So, I'm not worried about maintaining the same at this point (except for replicas within a test SDE), as long as they don't do weird things to my testing.  If you think they might, how do you usually remove and re-add them?  Any gotchas?

Reply
0 Kudos
Highlighted
MVP Esteemed Contributor

I host a local enterprise geodatabase, 10.3.1, SqlServer 2014 and have a number of remote clients access it.  While I encourage them to 2-way replicate, some do not have the enterprise geodatabse infrastructure in place, so they perform edits remotely.  It can be a glacial process, especially drawing the full extent.  Even for me, calculations and saves seem really slow.  To speed things up, you might try turning off certain features until the desired extent is obtained.

Like I said, the only way I know how to change global id values is to drop the and then re-add them; can't think of any gotchas.  Just drop the field and re-add it is what I've done.  I suspect you have a much larger database than I do, so you may not gain anything by creating empty feature classes in Test2 based on Test1, sans the global id. Then load or append the Test1 features into Test2, and then finally add guids to Test2.

Highlighted
MVP Esteemed Contributor

Thanks for the info Joe. All very helpful.  I'll keep the drop-field and re-adding of globalid as an option if/when I start running into any issues.  For now I'll continue without creating new....just to see if it does start showing weird behavior.

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

Apologies for the late response to this thread. I was out on business travel last week.
Looks like Joe Borgione‌ already answered Rebecca Strauch, GISP‌ question. Great!

Reply
0 Kudos