Error: ???synchronize replica failed???,

[Anonymous User]

Original User: Jamal432@gmail.com

Error: �??synchronize replica failed�?�,

I wanted synchronize the data from enterprise geodatabase to file geodatabase with replica name that has previously created but I got the message below:


[ATTACH=CONFIG]30200[/ATTACH], [ATTACH=CONFIG]30201[/ATTACH], [ATTACH=CONFIG]30202[/ATTACH]


What might be the issue here?

Thank you

Best

Jamal

[JamalNUMAN]

The potential 1000 record issue as mentioned in the bug report Asrujit pointed out, is not about the total number of records a Feature Class has, but about how many records you need to synchronize between the two replicas. E.g. if you deleted over 1000 records in the parent, and these now also needed to be removed from the child / relative replica, than you may run into this issue.

So the question is, did you delete over 1000 records from the layer having a problem synchronizing?

Hi Marco,

It happens that more than 1000 records are deleted. I got the error shown in the screenshot below:

[ATTACH=CONFIG]31043[/ATTACH]


is this issue solved in 10.2.1?

[Anonymous User]

Original User: mboeringa2010

It happens that more than 1000 records are deleted. I got the error shown in the screenshot below:
...
is this issue solved in 10.2.1?

Looking at the NIM bug entry Asrujit pointed out, it is still listed as "Open", so I guess not.

It may be good to contact ESRI on this one in an official support call. Even if they can't help you at this point in time, it will at least be another official log that stresses the need to get this fixed (although "Severity" is already recognized as "High").

[AsrujitSengupta]

Jamal,

This Bug has not been resolved at 10.2.1 yet, as the link suggests.

[Anonymous User]

Original User: Jamal432@gmail.com

Jamal,

This Bug has not been resolved at 10.2.1 yet, as the link suggests.

Thanks Marco and Asrujit for the contribution.

I�??m not sure if the �??official support call�?� is included in the software maintenance.

However, fortunately, this problem has direct workaround. I just delete the destination geodatabase and recreate another one and then apply the replica.

[WilliamCraft]

If you are deleting and replacing the replica geodatabase entirely as a workaround, why not just consider a different approach to achieve your goal?  Depending on your workflow and requirements, you may not even need to use replication.  Would it be feasible for you to simply generate an export of the data you need at a specific interval?  Instead of performing a synchronization only to find out that it doesn't work if there are 1,000 or more deletes, you might save yourself more time to just use the export or copy GP tools to produce the output file geodatabase altogether.  Then you could delete the output prior to re-exporting your data each time.  One of the reasons for using one-way replication is to avoid having to re-generate the entire geodatabase when changes are made; hence it allows you to simply export the deltas and apply them to the replica.  If you are finding that you need to re-generate the entire replica each time, it seems self-defeating to use replication.  If you must use replication based on your requirements, you could consider synchronizing twice instead of once so that you don't run into the 1,000-record deletion issue.  For example, sync once after 500 deletes and then again after 500 more deletes.

[Anonymous User]

Original User: Jamal432@gmail.com

If you are deleting and replacing the replica geodatabase entirely as a workaround, why not just consider a different approach to achieve your goal?  Depending on your workflow and requirements, you may not even need to use replication.  Would it be feasible for you to simply generate an export of the data you need at a specific interval?  Instead of performing a synchronization only to find out that it doesn't work if there are 1,000 or more deletes, you might save yourself more time to just use the export or copy GP tools to produce the output file geodatabase altogether.  Then you could delete the output prior to re-exporting your data each time.  One of the reasons for using one-way replication is to avoid having to re-generate the entire geodatabase when changes are made; hence it allows you to simply export the deltas and apply them to the replica.  If you are finding that you need to re-generate the entire replica each time, it seems self-defeating to use replication.  If you must use replication based on your requirements, you could consider synchronizing twice instead of once so that you don't run into the 1,000-record deletion issue.  For example, sync once after 500 deletes and then again after 500 more deletes.

Thanks William,

�?� The only reason I replicate the enterprise geodatabase to file geodatabase is the performance. I gain some considerable speed in case my web mapping application reads from the gdb but not from mdf.

�?� It is much efficient to replicate the enterprise geodatabase to file geodatabase rather than copying the enterprise to file. In case of light changes on the enterprise, these changes can be easily reflected to the file geodatabase by synchronizing them without the need to copy the ENTIRE geodatabase to file geodatabase

�?� The 1000 records deletion limitation is an issue that I expect to be solved by ESRI.

[WilliamCraft]

�?� The only reason I replicate the enterprise geodatabase to file geodatabase is the performance. I gain some considerable speed in case my web mapping application reads from the gdb but not from mdf.

�?� It is much efficient to replicate the enterprise geodatabase to file geodatabase rather than copying the enterprise to file. In case of light changes on the enterprise, these changes can be easily reflected to the file geodatabase by synchronizing them without the need to copy the ENTIRE geodatabase to file geodatabase

�?� The 1000 records deletion limitation is an issue that I expect to be solved by ESRI.

Regarding your first bullet, I would say that exporting or copying the data as I suggested still results in a file geodatabase.  You don't need replication to use or produce a FGDB.  Thus, you're not gaining anything by using replication for this reason alone. 

Regarding your second bullet, I agree with you that it is more efficient to export and apply changes to a replica rather than re-produce the entire geodatabase to a FGDB.  I basically stated this in my last post.  That being said, as a workaround you have already stated that you need to re-create the entire replica anyways so this really should not matter.  Furthermore from my experience, replication comes with plenty of buggy behavior and a number of hard requirements that you would not otherwise have with exporting your data to a file geodatabase using Export or Copy.  If you have any geometric networks that you are replicating, you will see huge wait times before the network is completely rebuilt on the child replica... especially with re-creating the entire replica as you are doing.  You wouldnt see this with a copy or export.  If this is not an issue for you or if you don't have geometric networks that you're working with, then it's probably not a big deal as long as you're willing to muddle through the rest of the challenges with Esri replication.  Hopefully you've had better luck than me. 

Regarding your third bullet, I wouldn't hold your breath about getting this fixed especially since it was reported at a recent release of 10.2.  Even if there is a documented NIM, it could be months before it's fixed.

[Anonymous User]

Original User: Jamal432@gmail.com

Regarding your first bullet, I would say that exporting or copying the data as I suggested still results in a file geodatabase.  You don't need replication to use or produce a FGDB.  Thus, you're not gaining anything by using replication for this reason alone. 

Regarding your second bullet, I agree with you that it is more efficient to export and apply changes to a replica rather than re-produce the entire geodatabase to a FGDB.  I basically stated this in my last post.  That being said, as a workaround you have already stated that you need to re-create the entire replica anyways so this really should not matter.  Furthermore from my experience, replication comes with plenty of buggy behavior and a number of hard requirements that you would not otherwise have with exporting your data to a file geodatabase using Export or Copy.  If you have any geometric networks that you are replicating, you will see huge wait times before the network is completely rebuilt on the child replica... especially with re-creating the entire replica as you are doing.  You wouldnt see this with a copy or export.  If this is not an issue for you or if you don't have geometric networks that you're working with, then it's probably not a big deal as long as you're willing to muddle through the rest of the challenges with Esri replication.  Hopefully you've had better luck than me. 

Regarding your third bullet, I wouldn't hold your breath about getting this fixed especially since it was reported at a recent release of 10.2.  Even if there is a documented NIM, it could be months before it's fixed.

Many thanks William,

I used to synchronize from enterprise geodatabase to file geodatabse unless:

�?� Field(s) are added to feature classes of the source geodatabase
�?� Layers are added to the source geodatabase
�?� More than 1000 features are deleted in the one (or more) layers in the source geodatabase

If one of the three events above occur, then �??synchronize�?� fails to update the destination geodatabase accordingly. In this case, I delete the destination and re-create the replica.

If none of the above events occur, then �??synchronize�?� will do the job with no problem


Best

Jamal

[Anonymous User]

Original User: MLF

Hello!  I have just experienced this error.  In my case, I know that if an invalid record is introduced to the parent database, the replica will fail.  There are two ways to fix it: either rebuild the replica, in which case the invalid records will replicate, or fix the invalid records and the replica works again. 

In this case today, I found and fixed the invalid records, but the replica still fails, and throws the same error referenced above.  This is the first time invalid records have been introduced since we migrated our clients to 10.2, but our database is still on 10.

Only ~300 records were changed, so we are well below the 1000-record threshold referenced in the bug (2 features were invalid).

It will be unfortunate for our workflows (15 replicas synch every night/replica rebuild can only happen after hours, etc.) if this is a new issue starting in 10.2, but I'm not clear how the client version would matter.

[Anonymous User]

Original User: MLF

to update:

I downgraded a workstation to version 10.1 and the replica synchronized successfully.  After this successful synchronization, I tried again from the 10.2 client, and it worked (but no changes to transfer).  I then added a record to the parent geodatabase so there would be changes to transfer, and synchronization from 10.2 was successful.

There are two replicas related to this data--one is a file geodatabase, the other is an SDE geodatabase, both one-way.  The same issue presents in both.