We are having an issue where after we sync from one geo database to another, and then a rec and post happens in the child geodatabase, the child geodatabase is showing duplicate global IDs in the base table. This appears to be occurring when there is an edit in the parent geodatabase that is then synced to the child geodatabase.
It is a two-way sync but the parent is set up as the geodatabase to use in case of conflicts. This doesn't appear to occur with all our tables, but we are noticing it a lot since upgrading from 10.1 to 10.2.2 in certain tables.
In this case, we'll see in the parent geo database the original record still in the base table, and the edited version in an edit version. It doesn't seem to rec and post to the base table.
What appears to be happening is, that the edit from the parent geodatabase comes over to the child database but for some reason gets either rec and posted to the base table without getting rid of the previous edit or gets posted directly to the base table. In effect, we get two records in our base table with dupe global IDs. And with every sync, rec and post, the number of dupes seems to grow each week.
Has anyone else experienced this? We are talking about a table with thousands of rows. We cannot pin point why this is happening and it's a very important table in our geo database.
The table is versioned and is also set for archiving. But, this issue has been on-going before we enabled archiving. We were able to remove the dupes before enabling archiving but now they are back and we don't know why. We're wondering if it's the replica between the two databases, but it used to work before 10.1 and now this has occurred since upgrading to 10.2.2.
Any help would be appreciated.
Dan, thanks for the link but that's not the issue we are seeing unfortunately. In this case, the global ID is already created in the base table and an edit to that record is showing up in a version in the parent geo database.
When we sync to the child geo database, it appears that the record get's synced or eventually, rec and posted to the base table, but the previous edit is also still in the base table.
Geodatabase A (parent):
Here's after the user has edited the record, setting the point_x column (blured out user id of editor):
We then do a rec and post in the parent database and then sync to the child database. After a rec, post in the child database, here is what we see (both in the evw and the base table):
Notice the dupe global ids. Object IDs are of course different as they should be, but you can see if you compare the records from the parent database to the child database that they are the same records, but for some reason, in the child database, it didn't rec and post correctly and rather than getting rid of the previous/original edit (state 0), it keeps it and then adds a new record.
Could the lineage be screwed up for this feature layer/table? Again, it is set to versioned and also archiving, but this issue persisted before archiving was enabled and didn't show itself until after we upgraded to 10.2.2, although that might just be a coincidence.
These records are getting edited in the parent geodatabase via ArcMap by our map editors. So, I don't know if it's something they are doing or not.
Also, in the parent geodatabase, we are noticing the edits will not rec and post back to the base table, so we still have 2 versions sitting out there in the parent geodatabase: one in the base table and one in the EVW view. Could this also part of the issue as to why we are getting dupes when we sync? Is it possible that these two edits in the parent geodatabase are seen as two different, disconnected records? I did look in the states table of the child database for that sde_state_id and cannot find where the state id ever maps back to state 0, so something is getting lost in the sync.
I have never seen global ids repeated in the data I manage with replication and I've always left this unchecked:
Not sure if checking this option is a contributing factor to your issue...
Thanks for the reply, Joe. No, we do not have that option checked. I've verified that to be sure and it does not state in the General tab of the properties window that it is to move edits to base. It only states that it is registered as versioned. So, definitely it's not that. Also, this class is used in replication, so we wouldn't be able to replicate if that option was checked.
I'm beginning to wonder if the states and lineages are out of whack?
Ivan--ran across your interesting (aggravating) problem. Did you ever sort this out? Did you talk to Esri? I got to wondering about which geodatabase version you were using, which database you were using, and whether you were able to replicate this problem in a test environment. -W