Replication Sync Error: Table Already Exists

6938
26
11-13-2012 12:04 PM
IanKramer
New Contributor III
Hi,
Has anybody seen a "Table already exists" error when trying to sync a replica?

Ok, here's my details. Both servers are Windows 2008 R2 64-bit, running SQL Server 2012, with ArcGIS 10.1 SP1. The Parent GDB is using a version specifically set up for the replica, which is derived off of a QA/QC version. The child uses the DEFAULT version. Both use the SDE user and its set up as a 2-way replica.

We already have copies of the data at both locations, so I created a custom ArcObjects tool that registers a feature class with an an existing replica, which specifies the "Register Only" option. This code is taken directly from the samples pages and deployed as a custom GP tool. The reason I choose this route is because I need to register over 100 feature classes, within a single replica, and I didn't want to do it manually using ArcMap. This process works fine. After it created, I sync'ed the replica and it worked with no errors. I then found a set of 5 feature classes, that had a different amount of features (missing features in one and not the other) before the replica was set up. I identified the "differences", made a copy of them in a FGDB, deleted them from the parent version, and appended them into the version from the FGDB. In essence, I treated them as newly edited (inserted) features. This was done because these feature classes participate in other versions that are actively being edited at both locations and I can't reload them at either location. Plus I needed to fool the replication process into copying them over to the child so that I could preserve the GlobalID's.

After this was done, I reran the sync and I get "Table already exists". Here is an excerpt from the ReplicaLog.dat file.

<ReplicaMsg time='11/13/2012 3:13:10 PM' type='LOG_MESSAGE_TYPE_DEBUG' code='' elapsed='0.000000 mins' method='TransferingInsert' objectClassName='Vector.SDE.spill_containment_feature_area' replicaName=''>Inserting {40AF74B7-5E91-45C6-B556-7E24CF98B065} feature</ReplicaMsg>


<ReplicaMsg time='11/13/2012 3:13:10 PM' type='LOG_MESSAGE_TYPE_WARNING' code='' elapsed='0.003733 mins' method='TransferingChanges' objectClassName='Vector.SDE.spill_containment_feature_area' replicaName=''>Table already exists - Vector.SDE.spill_containment_feature_area</ReplicaMsg>

I have no idea why its trying to recreate the feature class since it already exists and is registered with the replica. There were no replica or schema changes made to the replica's objects since its creation.

Ok, so then I tried to do a manual export/import. I got this error when importing the changes to the child.

"Import Changes Failed. Table Already Exists. The workspace is not connected. The workspace is not connected...."

Has anybody experienced this before? Thank you!

Ian
0 Kudos
26 Replies
ShannonShields
Esri Contributor
I would have expected a patch by now.


http://support.esri.com/en/downloads/patches-servicepacks/view/productid/67/metaid/1954

A patch was released in early February.

-Shannon
0 Kudos
IanBroad2
New Contributor III
http://support.esri.com/en/downloads/patches-servicepacks/view/productid/67/metaid/1954

A patch was released in early February.

-Shannon


Thank you!
0 Kudos
IanBroad2
New Contributor III
http://support.esri.com/en/downloads/patches-servicepacks/view/productid/67/metaid/1954

A patch was released in early February.

-Shannon


After reading the information about the patch, I'm still unsure if I need to be using the 2008 R2 SQL native client or can I now use the 2012 native client?
0 Kudos
ShannonShields
Esri Contributor
With the patch installed, you can use the 2012 Native Client again.

-Shannon
0 Kudos
IanBroad2
New Contributor III
With the patch installed, you can use the 2012 Native Client again.

-Shannon


Woohoo! Thanks.
0 Kudos
EzequiasRodrigues_da_Rocha
New Contributor III
It really solves the problem even on 2012 but i still got the recurrent message below:

000743 : Reconcile failed during replication synchronization.

Even taking the replica out of conflict.

Does anyone experienced this before?


- Ezequias Rocha
0 Kudos
deleted-user-vpHnfyiCToFz
Occasional Contributor

Ezequias,

I've converted the python scripts to auto synch on a schedule from the database server.  That way, I don't have to worry about which version of the native client I have on the machine running the synchronization.  Call me 'Garfield' or Lazy IT.  I just don't want to experience these errors anymore.  I've been running this from the Database server for over a year without complications.  Try testing the synchronization from multiple native clients to see if you get the same response.

Luke

0 Kudos