Skip navigation
All Places > Esri Technical Support > Blog > Author: TMorgan-esristaff

What is it?

The synchronization process is made up of multiple tasks involving sending and receiving data and acknowledgements between the two geodatabases that participate in the replica.  The Disconnected Synchronization process allows the user to manually complete each of these individual tasks. 

One way to think of synchronization can be to compare it to a phone conversation between two people, speaking and listening to each other.


Why use it?

To provide a method of synchronization for customers with replication between geodatabases that are in a disconnected environment.

To troubleshoot issues with replicas in a connected environment.

To get a deeper understanding of the synchronization process.


How to use it?

There are three ways you can access the tools needed to perform a disconnected synchronization.


                           ArcCatalog Context Menu:                                        ArcToolbox Geoprocessing tools:                                                  


ArcMap Distributed Geodatabase toolbar:


Before running any tools, use the replica manager to confirm which geodatabase in your replica is the data sender.  *Always check this status from both the parent and the child.





Step 1: Export Data Changes from the Data Sender.



If you are using a two way replica, and need to synchronize data in both direction, check the 'Switch to being a receiver once the message has been exported' so this workflow can be done in the opposite direction later.


Exporting the changes to Delta Geodatabase allows you to see the records with updates, inserts, and deletes that are being synchronized.  If features have not been updated, inserted or deleted since the last synchronization then you will not see those records in your Delta Geodatabase. 


Esri Support insight:  If other synchronization methods fail, this is my go-to option for troubleshooting that failure.




This step can be compared to saying “Hello” to start a conversation.



Step 2:  Import those data changes into the Data Receiver using the Import Messages Wizard.  Since our output in step 1 was a file geodatabase, we will choose to import a delta file geodatabase here.



This step can be compared to hearing someone say “hello” to you to start a converstaion.



Step 3:  Export an Acknowledgement Message from the Data Receiver.  This output will be an XML document.



This step can be compared to saying “hello” back to someone who just greeted you.



Step 4:  Import that Acknowledgement Message into the Data Sender. 



This step can be compared to someone hearing your “hello” reply.



The four steps are needed in order to perform a synchronization in one direction of a single replica.  If you are using a two way replica, and need to send data in both directions, then you will need to repeat these four steps again in the opposite direction.


*Use the Advanced tab in the Replica Properties to see the history of your replica geodatabases conversations. 


                 Parent geodatabase Replica Properties                             Child geodatabase Replica Properties                                            


  • The Current Generation of the Data Sender increases when data changes are exported from the sender geodatabase.
  • From the Data Receiver, The relative replica generation increases when new data changes are imported into the receiver geodatabase.
  • The Last Acknowledged Generation of the Data Sender increases when this geodatabase imports the acknowledgement message





For Fun!

*Always check this status from both the parent and the child.

Now that you have completed the disconnected synchronization workflow, let’s look at the statement above. 

  • Can you now think of WHY it is important to check the status from both the parent and the child? 
  • If you see both the parent and the child have the same status, what would you do to reconcile that so that only one geodatabase is the sender, and the other is the receiver?


*Use the Advanced tab in the Replica Properties to see the history of your replica geodatabases conversations.

This blog uses images to show the generations of a parent and child geodatabase.  In the images, the generations are "in sync", meaning that the conversation between the two geodatabases is said hello, and the other said hello back.

  • The generation numbers are 3-3-1 in the parent, and 1-1-3 in the child.   Can you determine how many times the parent has sent data to the child?  Can you determine how many times the child has sent data to the parent?
  • Can you determine what needs to be done if those numbers were 3-2-1 and 1-1-3?





We have all been there.  Your stomach is growling, yet all of your mental energy is focused on fixing the car in front of you going fifty in the fast lane.  When people are hangry (hungry/angry) they may come off irritable and agitated, maybe even point out every little thing that is going wrong, when the issue at hand is as simple as “I am hungry.  Feed me!”. 

Misdiagnosis happens all the time and can translate into many other facets of life, including software issues, but could you diagnose software issues when it seems like your software is being hangry?

The good news is that with some practice, and skills of observation, anyone can categorize software issues like a pro.  This blog will help guide you when encountering software issues.  The intention is to lift the many layers that can complicate issues, so that you may accurately, yet simply state the issue you need help with.


Symptoms of software issues are observable by the end user in many forms, such as an error, performance degradation, or a software crash, to name a few.  Hopefully, these interruptions prompt users to call to Esri Support and log a case for investigation.  At Esri Support, our analysts have a specific skillset.  Few of us are generalists, and this structure is designed to provide our customers with elite technical support…in other words, we don’t use scripts. 

Why is this important?  One of the first steps to logging a case with Esri Support is providing a description of the issue, which will be used to form a subject line in the case.  These subject lines can be altered as more knowledge is gained on the issue through investigation, but this initial subject line is big factor in determining which analyst owns the case first. 


Determining the overall symptom helps guide the triage process and the lifetime of the case.   Let’s explore these symptoms in more detail.


1.  Error: 

Error messages will stop us in our tracks.  Sometimes the messages are very useful, and tell us exactly what we need to know to proceed, sometimes not so much.  When users encounter errors we always request a screenshot of the error and the workflow (clicks) leading up to the error.  For example, “Error: invalid coordinate system identifier” is seen when adding data from an Oracle enterprise geodatabase into ArcMap.


2.  Performance degradation:  

Personally, this is the most frustrating issue to encounter.  There is no error; instead, the process is slow, and the spinning hour glass doesn’t tell you when you can expect performance to return.  When performance cases come to my desk, I first gauge the slowness, because “slowness” is a relative term, and something that is slow in one environment may be optimal in another.  The symptom here isn’t just performance, but specifically performance degradation.  In other words, there was a more optimal performance, which has now degraded.

Symptoms of slow performance can be caused by many things including workflows, overloaded resources, and software compatibility to name a few.   To get started troubleshooting it is always helpful to have a comparison case available for investigation.  If you believe you are seeing slowness in software, first ask yourself ‘this is slow compared to what?”  

For example, “using ArcMap 10.1 sp1 to do the same workflow on the same data takes 1 seconds, while using ArcMap 10.5.1 takes 20 seconds”, or “Previewing feature class A in ArcCatalog takes 1 second, while previewing feature class B takes 20 seconds.  Both features are stored in the same enterprise geodatabase”. 

These examples give us a “fast” example and a “slow” example that can be compared to each other.  Notice in these examples that there is only one difference in the workflows, giving us controlled variables and a single dependent variable to review…right, like scientists.


3.  Unexpected results:  

This symptom, like performance, will not produce an error, but unlike performance symptoms, these processes will complete, seemingly successful.  However, when the results are analyzed they are incorrect or incomplete.   Unexpected results can also take the form of tools being disabled, or grayed out. 

For example, “I open ArcCatalog to enable Editor Tracking on my feature class, but Enable Editor Tracking is grayed out”, or “I created a replica of my U.S. States feature class, but only 48 of the states were replicated into the child geodatabase”.

Most of the time unexpected results stem from a workflow issue.  Some setting that needed to be turned on for this tool to work was not turned on, or properties/constraints on this data caused the unexpected results.  In the first example above the connection must be made as the data owner to enable Editor Tracking.  Any other user connection will see the Editor Tracker option grayed out.  The second example, where not all data has been replicated, may be due to filters placed on the data being replicated, or relationship classes enforcing database referential integrity.  


4.  Crash:

Click, click boom goes the dynamite.  There is no error.  The best you can do is re-open the software and try again.  Esri considers all crashes a bug.  We want our software to give you a meaningful error that will help you complete your work.  Crashes occur when the software encounters an argument that it doesn’t know how to resolve.  Always report crashes to Esri Support so we can ensure our software understands how to handle these situations.


Software issues can be complex, can employ multiple technologies that require different levels of expertise on many different subjects.  These issues can be more approachable by answering the question, “What did I observe during my daily work that prompted me to request help”?   While there are always exceptions, 90% of the time I can start answering that question with one, or more, of the symptoms discussed in this blog.   I hope this helps brighten up the perceived darkness around software issues, and as always, give us a call if you encounter any of these issues, or just have questions for us. 



As a Support analyst, I take for granted how easy it is to say the words “how can we help you?” But as a software user, I understand answering that question can be difficult.  My expertise lies in the enterprise geodatabase, and even with my near decade of experience, I can still get overwhelmed when discussing other technologies. 


Esri Support has taught me enough to fill a novel, so for the sake of your time, here are a few rules of thumb I live by when discussing technical details with customers, management, engineers, and development alike…

  • Write an accurate and detailed, yet succinct description of the issue. 

The subject line on a support case is often the first thing we Support analysts see.  A clear and universally understandable subject line can help your case get assigned to the right analyst the first time, and avoid unnecessary transfers. 

Hint:  Understanding the issue is key.  To help formulate a primo subject line by focusing  on the heart of your issue you can refer to my blog Understanding Software Issues


  • Use numbers and bullets to list steps in a workflow.

Paragraphs are great for storytelling, but bullets drive home details. 

Hint:  When reproducing the issue, think of each mouse click as a step in the workflow.  If there are 10 mouse clicks to reproduce the issue, then that workflow will have 10 bullet points.


  • Ensure the workflow starts at a point that your audience can relate to. 

The common ground you start on is relative, and can change depending on your and your audience’s combined experience.   

Hint:  If the first step in the workflow is to ‘click on the Manage Replicas button to open the replica manager’, then first make sure your audience knows where and how to find the Manage Replicas button. 

  1. Open ArcMap 10.5.1
  2. Click ‘Customize’ on the menu bar
  3. Expand ‘toolbars’
  4. Click on ‘Distributed Geodatabase’ to open the toolbar
  5. Click on the Manage Replicas tool


  • When in doubt about what to call a tool, open the software and call it what the interface calls it. 

For example, the terms ‘layer’ and ‘feature class’ are often used interchangeably in conversation, however, a feature class is data stored in a geodatabase, and a feature layer is a representation of that feature class, usually in-memory and often in a map.   These two items, while they look and act very similarly, will require different background and experience to troubleshoot.


  • Refrain from using pronouns, acronyms or industry specific language, unless they have been previously defined for both you and your audience.  Don’t assume that everyone knows what is meant by the “OPI”.  One person’s “Oracle Program Interface” is another person’s “Offensive Pass Interference” is another person’s favorite nail polish.


While no one knows everything, we all know something, and if we can clearly communicate ourselves, then combining that knowledge becomes much easier.  Ask questions, ask 20 questions if you must, because each question will help determine the most effective triage path to take (See my awesome colleague’s blog that discusses this method in more detail...  What Would Tech Support Do?). 


Esri Support Analysts practice this approach from day one.  I often recall my onsite interview where I was asked to explain to my future manager how to tie her own shoelaces with my back turned to her.  I thought “this will be easy. I can tie shoes with my eyes closed.”.   After about a minute of giving what I considered an award-winning description of how to tie shoelaces, I turned around to see her shoes did not even have laces!  I failed to ask the right questions and find our common ground.  That moment has taught me not to shy away from even the most basic questions, and has turned out to be very valuable when needing to describe technical details in a timely manner to people with wide ranges of technical experience.


So, whether you are just getting started, or a GIS guru, give us a call at Esri Support, where our first question will always be “How can we help you?”. 



As a support analyst, we get a range of fun issues to review. These issues may be specific to the user’s environment, data, workflow, etc. Sometimes, we may notice an influx of calls pertaining to a single workflow. When this happens, we revisit the resources our users have available to them, and ensure that the documentation clearly describes how to execute workflows.

One of these workflow issues we have seen in the call center lately has been working with schema changes in replicas. For example, after creating a replica, you realize you need to add a field to a certain feature class, or remove a domain that is no longer necessary. This blog hopes to make this workflow more intuitive with a few tricks that will help the replica gurus out there efficiently deal with schema changes.

Let’s review: when a replica is created, the data and schema of the objects being replicated are registered in the parent geodatabase and child geodatabase. The data is defined as the rows in the table and uses the GlobalId values as a link between parent and child, while the schema consists of the fields, domains, subtypes, and other properties that describe the replicated data. Remember, if you use the Distributed Geodatabase toolbar in ArcMap to create the replica, and use the option to 'Register existing data only', then the replica could have differing schemas upon creation. This is allowed as some organizations have a need for this diagram, so it is up to the replica creator to ensure that the data is prepared to their own needs before creating the replica.

Ideally, the schemas are identical on both replicas during replica creation, but over time, changes might be applied to each replica schema. For example, one replica may require additional fields to complete a project, while the relative replica may need to apply a new domain to an existing field. When this happens, the schemas of the replicas are no longer the same. Again, it is not required to have identical schemas in the parent and child geodatabases; however, if the differences are not intended, then you may see some unexpected behavior.

What can happen if there are schema differences in the replicated data?
  • Edits that don't synchronize- Data synchronization only imports changes for tables and fields that are common to both replicas.
    • Note: If schemas do not match when data is synchronized, the data is flagged as having been sent to its relative replica. Remember, replicas do not require schemas to match, but any and all edits will be flagged as synched during synchronization, whether or not there is a matching schema (for example, a field) in the relative replica to receive the edits.
  • Invalid values - Changes that violate domains, subtypes, connectivity rules, and relationship rules are applied when synchronizing changes. The validation tools on the editor can be used to check the newly imported values.
  • Data synchronization errors - This can happen when you manually make a schema change to both replicas. For example, you may want to add a field to a table. If you do this, be sure to make the exact same schema change in all cases. If there is a difference (for example, a field is a string on one replica but an integer in the other), a data synchronization error will occur.

    Synchronization error due to mismatched field types between replicas.

  • Unsupported changes - Some types of schema changes can cause synchronization to fail, but no warning is displayed if you make the change. These changes are not detectable by the geodatabase replication system. They include database-level operations like changing permissions on tables in the database. If permissions are changed to read-only for replicated data, a failure will happen when importing changes from the relative replica.
Applying schema changes across replicas - Modifying the schema of a replica to match the schema of a relative replica is a completely separate process from data synchronization.  If you believe you are encountering some of the unexpected behavior described above, you may use the following tools.

Three tools are provided to update replica schemas:
  1. Export Replica Schema - Used to export the schema from the geodatabase that has the schema you want applied to the relative replica. Typically only used for disconnected environments or scripting.
  2. Compare Replica Schema - Used to find the differences between the two geodatabases in the replica. This is always done from the geodatabase that you want the changes applied to. This is the first step if working in a connected environment.
  3. Import Replica Schema - Used to import the differences found during the replica comparison into the geodatabase that you want the changes applied.

The tools are available on the Distributed Geodatabase right-click context menu in the Catalog tree, Distributed Geodatabase toolbar in ArcMap, and as geoprocessing tools.

Distributed Geodatabase right click context menu in ArcCatalog


Distributed Geodatabase toolbar in ArcMap


Data Management Geoprocessing Tools

It is important to note that there are very slight differences in these three methods. For example, the Import Replica Schema wizard on the Distributed Geodatabase right-click menu from ArcCatalog and the Distributed Geodatabase toolbar in ArcMap list the changes that the user can opt to apply or not apply, while the geoprocessing tools (which are more often used in disconnected environments or scripted automatic processes) do not.

Lastly, keep in mind that the geoprocessing tools are typically used in a three-step process (Export, Compare, and Import) and are mostly used when this process is part of a scheduled task. The Distributed Geodatabase toolbar in ArcMap and the Distributed Geodatabase right-click context menu can be used in a connected environment and with only two steps (Compare and Import).

While eliminating the Export Replica Schema step can save you time, if there is doubt about which geodatabase schema should be the input for the tools, or doubt about which changes are being propagated, I find that the 3-step Geoprocessing Tool method can be much more intuitive. The first tool will always be the Export Schema Changes geoprocessing tool. This tool has only one geodatabase input (the geodatabase that has the schema you would like propagated to the relative replica), and creates a single output XML file.

Now, we run the Compare Replica Schemas geoprocessing tool where our input is the relative geodatabase and the XML file we just created. The output for the Compare Replica Schema Geoprocessing tool is a single XML file. Finally, our third step is to run the Import Replica Schema. Our input will be a geodatabase - the relative to the input we enter in the Export Replica Schema tool, and the compare.XML we just created. While the geoprocessing tools do not have the organized UI that lists the recognized schema differences, this method can clarify any confusion about where the changes are being taken from and where they are being sent to.See Resource documents:
Tina M. - Geodata Support Analyst
In a versioned environment, all edits are stored in what we call delta tables, or Adds and Deletes tables, and these tables are assigned to a unique state ID. Edits are held in the delta tables to handle any conflicts in a multi-user enterprise geodatabase. A compress operation trims the delta tables of any unreferenced state ids, consolidating the states lineage down to one state. If a state is still being referenced, it will remain in the delta tables, resulting in a partial compress.

In a fully compressed geodatabase, there are no rows in the delta tables, and the state tree is trimmed back to one state, state_id=0. Although a full compress is ideal, it is not always necessary and in some cases may not even be practical. For example, if there are many multi-generation replicas in your geodatabase that are not unregistered before the compress, you will need to send changes for all of these replicas to achieve a full compress. If there are many Two-way replicas, and you intend to fully compress both the parent and the child geodatabases, this process of synchronization will need to be done separately from both geodatabases, even if there are no changes to be sent.

Two important things are needed to get a full compress on a geodatabase that still has replicas registered.
  • The existing replicas must be the data sender in the replica relationship.
  • Every replica version must be at the same state as DEFAULT version.

This means that for Two-way replicas, there can be no SYNC_RECEIVE or SYNC_RECEIVE_REC versions in the geodatabase that need to be compressed.

The example below shows the parent geodatabase versions table. All versions associated with a single replica will contain a synchronization version id number in the version names. There are two replicas in this versions table. The One way replica, represented by the synchronization version ID number 10554, is a parent to child replica. Notice the DEFAULT state_id is 398, while this synchronization version is only at state_id 395. One-way replicas will only contain an associated replica version in the data sending geodatabase.

Going on, the replica with synchronization version 10552 is a two-way replica. Two-way replicas can be more complicated since the edits may travel in either direction, frequently switching the data sender and receiver roles. Notice that this two-way replica does have the SYNC_RECEIVE and SYNC_RECEIVE_REC versions associated with it, meaning that this version is in the data receiver role.

This example is making the assumption that there are no named child versions, and that connected synchronization is being used.11.jpg

To prepare this geodatabase for a full compress, I must do the following.
  1. Synchronize the one-way replica.
  2. Synchronize the two-way replica, sending changes from this geodatabase to its partner geodatabase. The image above shows the versions table in the parent geodatabase, and tells me that this parent is currently set as the data receiver; therefore, I will synchronize parent to child, in effect making this geodatabase the data sender.

The results of these two steps are shown in the image below.2.jpg

With all of my versions set as acknowledged data senders and with the state_id equal to the DEFAULT version, my geodatabase is ready for a full compress.3.jpg

Note that it is common to see these two requirements met, and yet only get a partial compress. If this is the case, synchronize the replicas in the geodatabase that need a full compress again. Even though no changes are being sent, acknowledgements are being sent that will tell the geodatabase that the edits are recognized and can be flushed from the delta tables.

In general, look to achieve some level of compress rather than a full compress. Attempting to achieve a full compress may lead to many additional synchronizations which may not be practical in your particular business workflow.
Tina M. - Geodata Support Analyst

Filter Blog

By date: By tag: