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.
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.
�?� 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.
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.
Jamal,This Bug has not been resolved at 10.2.1 yet, as the link suggests.
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?
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?
The layer that has a problem is with more than 1000 records...Meanwhile, I have another layer with about 240,000 records and had no problem when synchronized.
That looks like a pretty nasty bug, although deleting a thousand records in these kind of versioning environments, if properly managed, is probably not that common.Would be nice to know if Jamal actually hit that 1000 record wall. There may still be other issues.
Jamal,This is a known issue with Desktop 10.2 for now:[NIM094669 - Synchronizing replica after deleting 1000 or more records from parent geodatabasefails using ArcGIS Desktop 10.2]http://support.esri.com/en/bugs/nimbus/TklNMDk0NjY5You can use a previous version of ArcGIS Desktop to synchronize the Replicas as a workaround for now.
I don't know. The error indicates an issue processing some SQL statement. I recently got a similar error when I tried to access in ArcGIS a query stored in Access via ODBC. The query was based on other queries, one of which was a Crosstab query. Although I wasn't hitting this Crosstab query directly in ArcGIS (only another query using the Crosstab query in Access as one of its datasources), ArcGIS also gave the "An invalid SQL statement was used" error. I didn't expect this to happen, but only exporting the query to a new table in Access, solved the issue. Clearly, there are some limitations to what SQL statements may be used in this specific case in combination with ArcGIS.But this is all pretty much unrelated to your specific issue here I think.
At the end, do I need to delete the destination �??file geodatabase�?� and create another replica?
Have you changed anything on the SQL Server side related to that listed Roads_Ramallah Feature Class, e.g. created some SQL database views etc, removed or added fields, thus changing schema?
Signed in members can post, follow updates, and more. New here? Register a free account.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
