???synchronize changes??? doesn???t update the values of the target geodatabase,
A replica is built between an ArcSDE geodatabase (SQL Server database) and a file geodatabase with the settings below
[ATTACH=CONFIG]25146[/ATTACH]
Some changes occur on the file geodatabase and then the ???synchronize changes??? applied from the ArcSDE geodatabase to the file geodatabase as shown in the screenshot below:
[ATTACH=CONFIG]25147[/ATTACH]
The issue is that the feature classes of the file geodatabase (which participate in the replica) are not updated according the values of the ArcSDE geodatabase
1. I got two geodatabases one is ArcSDE geodatabse and the other is file geodatabase
2. I have created a one way replica FROM the ArcSDE geodatabse TO the file geodatabase
3. It happens that edits occurred on the file geodatabase (say by mistake!)
4. In this case, when the ???synchronize changes??? tool is applied FROM the ArcSDE geodatabse TO the file geodatabase then the edits that recently occurred on the file geodatabase don???t change while it is supposed that the file geodatabase must be updated to be as a copy of the ArcSDE geodatabase.
My point here is why the file geodatabase (after being edited) is not updated to be the same as the ArcSDE geodatabse when the ???synchronize changes??? tool is applied?
Jamal,
I must admit I am going on my theoretical knowledge here based on the Help documentation, I still need to try replication myself once with my test setup here at home...
But anyway: ArcGIS keeps track of edits on geometries by unique ID's (identifiers - GlobalID column). This allows ArcGIS to determine which geometries changed or not, and whether something needs to be replicated from one database to another. If you start editing the child file geodatabase, and add new features, these features will have ID's unknown to the parent SDE database, or no GlobalID at all. ArcGIS probably does not know what to do with these, as these records are not supposed to be there.
Some changes occur on the file geodatabase and then the �??synchronize changes�?� applied from the ArcSDE geodatabase to the file geodatabase as shown in the screenshot below:
Jamal, just to get this straight: The bold text should be "Some changes occur on the ArcSDE geodatabase"?!
You do intend to send changes done on the production ArcSDE geodatabase to the publication file geodatabase to be hosted on the internet in a One-Way replica?
Jamal, just to get this straight: The bold text should be "Some changes occur on the ArcSDE geodatabase"?!
You do intend to send changes done on the production ArcSDE geodatabase to the publication file geodatabase to be hosted on the internet in a One-Way replica?
Thank you so much Marco for the input.
My understanding that when one direction �??synchronization�?� is applied then the �??To�?� geodatabase will be exactly the same as the �??From�?� geodatabase. Therefore, just in case changes occur on the �??To�?� geodatabase then this geodatabase should be the same as the �??From�?� geodatabase after being synchronized with it.
When I create a replica from our production SDE to a publication SDE, in a simple one way replica, in the production SDE I connect using the sde account, and in the publication (destination) SDE, I connect as the data owner account in that Geodatabase.
My understanding that when one direction �??synchronization�?� is applied then the �??To�?� geodatabase will be exactly the same as the �??From�?� geodatabase. Therefore, just in case changes occur on the �??To�?� geodatabase then this geodatabase should be the same as the �??From�?� geodatabase after being synchronized with it.
Why this logic is not true in the ArcGIS?
Jamal,
I don't understand what you intend to say with the bold text. One-way is One-way.
1) If you intend the production SDE geodatabase to be the main database where all edits occur ("parent-to-child"), and the publication file geodatabase just a read-only copy of it that needs to be synchronized with the production database on a regular basis to show the changes that occured on the production database, than you need to set the direction of the one way replication FROM the parent SDE geodatabase TO the child file geodatabase.
This means you can not make changes to the file geodatabase and have them show up in the SDE geodatabase, but the child database can be a file geodatabase in this case.
As the ArcGIS Help says: "When creating a one-way, parent-to-child replica, the destination can be an ArcSDE, file, or personal geodatabase."
2) On the other hand, if you intend to make an editable web application as the source of all edits ("child-to-parent"), and allow users to edit features through a custom web application and have the changes send back to the SDE parent, than the child database MUST BE a SDE geodatabase too, it can not be a simple file geodatabase, as these do not support versioning, and therefore can not support replication as a source of edits.
As the ArcGIS Help says: "When creating a one-way, child-to-parent replica, both child and parent replicas must be hosted in an ArcSDE geodatabase."
3) Lastly, if you intend to edit both on the main production SDE geodatabase through ArcGIS for Desktop, and want to allow editing through a custom web application on a separate publication geodatabase, than both the parent production database and this publication database MUST BE SDE geodatabases, and the replication type should be "Two-way". You can not have a file geodatabase participate in two-way replication.
One last option though: If, like in 2), you need changes to occur on a "child" geodatabase, and you want this to be a file geodatabase instead of a more complex SDE geodatabase, than there is the specific last option of a "check-out, check-in" replica. The disadvantage of this type of replication though, is that you can only synchronize changes once. After that, you need to re-create the replica. This is fine for occassional "field-work" type edits, but becomes cumbersome when many / frequent edits to a check-out file geodatabase occur, and need to be regularily synchronized with the parent.
In addition, since versions are unsupported in the file geodatabase, you can not have concurrent edits by multiple editors going on against the "check-out" file geodatabase (well, at least not without the risk of over-writing each others edits without warning).
I don't understand what you intend to say with the bold text. One-way is One-way.
1) If you intend the production SDE geodatabase to be the main database where all edits occur ("parent-to-child"), and the publication file geodatabase just a read-only copy of it that needs to be synchronized with the production database on a regular basis to show the changes that occured on the production database, than you need to set the direction of the one way replication FROM the parent SDE geodatabase TO the child file geodatabase.
This means you can not make changes to the file geodatabase and have them show up in the SDE geodatabase, but the child database can be a file geodatabase in this case.
As the ArcGIS Help says: "When creating a one-way, parent-to-child replica, the destination can be an ArcSDE, file, or personal geodatabase."
2) On the other hand, if you intend to make an editable web application as the source of all edits ("child-to-parent"), and allow users to edit features through a custom web application and have the changes send back to the SDE parent (where no other edits may occur!), than the child database MUST BE a SDE geodatabase too, it can not be a simple file geodatabase, as these do not support versioning, and therefore can not support replication as a source of edits.
As the ArcGIS Help says: "When creating a one-way, child-to-parent replica, both child and parent replicas must be hosted in an ArcSDE geodatabase."
3) Lastly, if you intend to edit both on the main production SDE geodatabase through ArcGIS for Desktop, and want to allow editing through a custom web application on a separate publication geodatabase, than both the parent production database and this publication database MUST BE SDE geodatabases, and the replication type should be "Two-way". You can not have a file geodatabase participate in two-way replication.
One last option though: If, like in 2), you need changes to occur on a "child" geodatabase, and you want this to be a file geodatabase instead of a more complex SDE geodatabase, than there is the specific last option of a "check-out, check-in" replica. The disadvantage of this type of replication though, is that you can only synchronize changes once. After that, you need to re-create the replica. This is fine for occassional "field-work" type edits, but becomes cumbersome when many / frequent edits to a check-out file geodatabase occur, and need to be regularily synchronized with the parent.
In addition, since versions are unsupported in the file geodatabase, you can not have concurrent edits by multiple editors going on against the "check-out" file geodatabase (well, at least not without the risk of over-writing each others edits without warning).
Thank you Marco and Leo for the help. This is quite useful.
Sorry for the confusion.
The scenario that I got can be depicted in the following points:
1. I got two geodatabases one is ArcSDE geodatabse and the other is file geodatabase
2. I have created a one way replica FROM the ArcSDE geodatabse TO the file geodatabase
3. It happens that edits occurred on the file geodatabase (say by mistake!)
4. In this case, when the �??synchronize changes�?� tool is applied FROM the ArcSDE geodatabse TO the file geodatabase then the edits that recently occurred on the file geodatabase don�??t change while it is supposed that the file geodatabase must be updated to be as a copy of the ArcSDE geodatabase.
My point here is why the file geodatabase (after being edited) is not updated to be the same as the ArcSDE geodatabse when the �??synchronize changes�?� tool is applied?
Best
Jamal
---------------------------------------- Jamal Numan Geomolg Geoportal for Spatial Information Ramallah, West Bank, Palestine
1. I got two geodatabases one is ArcSDE geodatabse and the other is file geodatabase
2. I have created a one way replica FROM the ArcSDE geodatabse TO the file geodatabase
3. It happens that edits occurred on the file geodatabase (say by mistake!)
4. In this case, when the ???synchronize changes??? tool is applied FROM the ArcSDE geodatabse TO the file geodatabase then the edits that recently occurred on the file geodatabase don???t change while it is supposed that the file geodatabase must be updated to be as a copy of the ArcSDE geodatabase.
My point here is why the file geodatabase (after being edited) is not updated to be the same as the ArcSDE geodatabse when the ???synchronize changes??? tool is applied?
Jamal,
I must admit I am going on my theoretical knowledge here based on the Help documentation, I still need to try replication myself once with my test setup here at home...
But anyway: ArcGIS keeps track of edits on geometries by unique ID's (identifiers - GlobalID column). This allows ArcGIS to determine which geometries changed or not, and whether something needs to be replicated from one database to another. If you start editing the child file geodatabase, and add new features, these features will have ID's unknown to the parent SDE database, or no GlobalID at all. ArcGIS probably does not know what to do with these, as these records are not supposed to be there.
How would you imagine the ArcSDE instance could be aware of such an incorrect edit? If you corrupt your file geodatabase, you've violated the terms of the replication contract. The result of any subsequent operations are undefined.
How would you imagine the ArcSDE instance could be aware of such an incorrect edit? If you corrupt your file geodatabase, you've violated the terms of the replication contract. The result of any subsequent operations are undefined.
- V
Many thanks Marco and Vince. This is what I wanted to know.
The takeaway is that for this 1-way parent-to-child replica, the assumption is that the child is read only. If you perform edits on the child, the replication process will not inspect your data on the child to see what has changed, as it is expected to be read-only. If however on the parent, you edit the same data that was 'mistakenly' edited on the child, you should see those child records replaced by the edits from the parent when you perform a synchronize.
The requirement for the child to be a read-only goedatabase is not enforced by replication; the onus is on the user to decide if they want to proceed with editing the child data and risk subsequent data overwrite.
"In one-way, parent-to-child replication, the data in the parent replica is editable, but the data in the child is considered read-only. If edits are performed on the data in the child replica data, the edits are overwritten if they conflict with edits applied during synchronization"
