Latest Contributions by TinaMorgan1

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 completed...one 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? esrisupport‌ ... View more

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.  esrisupport‌ ... View more