New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions
Mail Us support@pass4success.com
Location US
Mob_nav_barsMENU

Esri EGMP2201 Exam - Topic 1 Question 16 Discussion

Actual exam question for Esri's EGMP2201 exam
Question #: 16
Topic #: 1
[All EGMP2201 Questions]

A data owner creates a one-way replica parent-to-child for a single feature class to share data from a production geodatabase to a public-facing geodatabase.

* The data owner synchronizes once a week to share updated data

* In time, the data owner wants to add a new attribute field/field type and calculates new attribute values

* The data owner synchronizes the replicas, but the new field and values are not present in the child replica

* In the public-facing geodatabase, the data owner adds the same attribute field and field type

* The data owner synchronizes the replicas again, and the values are not replicated in the child replica

How should the data owner resolve this issue?

Show Suggested Answer Hide Answer
Suggested Answer: C

Scenario Overview:

A one-way replica from parent to child geodatabase is created for a single feature class.

The data owner adds a new attribute field in the parent geodatabase, calculates values, and attempts to synchronize the replica.

The new field and its values do not appear in the child replica, even after manually adding the field to the child geodatabase.

Why Recreate the Replica?

The issue arises because schema changes (e.g., adding new fields) are not automatically propagated in one-way replication workflows. Synchronization only applies to data changes, not schema updates.

To ensure the schema changes are recognized, the replica pair must be recreated with the updated schema. (ArcGIS Documentation: Geodatabase Replication and Schema Changes)

Steps to Resolve the Issue:

Unregister the Replica: Remove the existing replica pair from both the parent and child geodatabases.

Recreate the Replica: Create a new one-way replica between the parent and child geodatabases. This new replica will include the updated schema.

Synchronize Changes: Perform synchronization to transfer data, including the new field and calculated values, to the child geodatabase.

Alternative Options:

Option A: Enabling replica tracking does not address schema synchronization and would not resolve the issue.

Option B: Running Feature Compare is helpful for analyzing schema differences but does not propagate schema changes.

Thus, the data owner must unregister the replica pairs, recreate the replica with the updated schema, and synchronize changes to resolve the issue.


by Barrett at Jul 14, 2025, 04:14 PM

Limited Time Offer

25%

Off

Get Premium EGMP2201 Questions as Interactive Web-Based Practice Test or PDF

Contribute your Thoughts:

0/2000 characters
Submit Cancel
Willow
3 months ago
Unregistering the replicas seems like a hassle, but it might be necessary.
upvoted 0 times
...
Celia
3 months ago
I think option C is the best way to go!
upvoted 0 times
...
Tyisha
3 months ago
Wait, why aren't the new fields syncing? That's odd.
upvoted 0 times
...
Emerson
3 months ago
I disagree, Feature Compare should work just fine!
upvoted 0 times
...
Aileen
3 months ago
The data owner needs to recreate the replica for sure.
upvoted 0 times
...
Celeste
4 months ago
I feel like recreating the replica is necessary when changes like this happen, but I can't remember if there's a specific order to follow.
upvoted 0 times
...
Xuan
4 months ago
I think the answer might involve running Feature Compare, but I can't recall if that's the best option here.
upvoted 0 times
...
Junita
4 months ago
This question feels similar to one we practiced where we had to recreate a replica after adding fields.
upvoted 0 times
...
Rickie
4 months ago
I remember something about unregistering replicas, but I'm not sure if that's the first step.
upvoted 0 times
...
Devon
4 months ago
This question seems straightforward enough. I think the solution is to unregister the replica pairs, run Enable Replica Tracking, and then Synchronize the Changes. That should resolve the issue with the new attribute field and values not being present in the child replica.
upvoted 0 times
...
Tien
5 months ago
Okay, I think I've got a strategy for this. Based on the information provided, it seems like the best approach would be to unregister the replica pairs, recreate the replica, and then synchronize the changes. That way, we can ensure that the new attribute field and values are properly replicated in the child replica.
upvoted 0 times
...
Alaine
5 months ago
Hmm, I'm a bit confused by this question. I'm not sure if unregistering the replica pairs and then running Feature Compare and Synchronizing the Changes would be the best approach. Maybe we should try unregistering the replica pairs and then recreating the replica and synchronizing the changes instead?
upvoted 0 times
...
Laurel
5 months ago
This seems like a tricky one. I'm not entirely sure how to approach it, but I think unregistering the replica pair and then trying to re-enable replica tracking and synchronize the changes might be a good starting point.
upvoted 0 times
...
Enola
6 months ago
Option C is the clear winner here. Anything less and the data owner might as well just start a weekly hokey-pokey dance with the geodatabases.
upvoted 0 times
Elbert
5 months ago
Option C is the best choice for resolving this issue.
upvoted 0 times
...
...
Rossana
7 months ago
I'm just imagining the data owner frantically trying to figure this out, like a modern-day Sisyphus pushing that boulder up the hill every week. C is the way to go!
upvoted 0 times
...
Melvin
7 months ago
Option A sounds like a band-aid approach. If the data owner really wants to add a new field, they need to go with C and start fresh.
upvoted 0 times
...
Dean
7 months ago
That's a good point, Tyra. It might be worth considering option C as well.
upvoted 0 times
...
Cordelia
8 months ago
I'm torn between B and C. Feature Compare might be a quicker fix, but recreating the replica is probably the safest long-term solution.
upvoted 0 times
...
Tyra
8 months ago
But wouldn't recreating the replica, like in option C, also solve the issue?
upvoted 0 times
...
Lauryn
8 months ago
I agree with Dean, enabling replica tracking might help.
upvoted 0 times
...
Wendell
8 months ago
Definitely C. Unregistering the replica and recreating it from scratch is the only way to ensure the new field and values are properly synced.
upvoted 0 times
Lorrie
7 months ago
Definitely C. Unregistering the replica and recreating it from scratch is the only way to ensure the new field and values are properly synced.
upvoted 0 times
...
Marcos
7 months ago
C) Unregister the replica pairs, recreate the replica, and Synchronize Changes
upvoted 0 times
...
...
Dean
8 months ago
I think the data owner should choose option A.
upvoted 0 times
...

Save Cancel