Skip navigation
All Places > Esri Technical Support > Blog > 2015 > March
2015
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
This blog post provides updated deprecation information regarding ArcGIS 10.3 and 10.2.x. The first version of the 10.3 series was released in December 2014.

Starting in 2014, with the release of ArcGIS 10.2.1, the pattern for the deprecation plan changed from a once-a-year release format to an update for every release. The deprecation plan also expanded to cover apps, mobile, and ArcGIS Runtime SDK products. As a result, with the latest releases of ArcGIS products, the deprecation plan has been updated.

Here are some of the major changes in the update for ArcGIS 10.3:

  • Esri will continue to ship the Microsoft Visual Basic for Applications (VBA) compatibility setup with ArcGIS, as long as we continue to ship ArcMap or until Microsoft notifies us that we can no longer distribute VBA.
  • Support for Microsoft SQL Server 2008/2008 R2 ends with the last release of the ArcGIS 10.3 series (ArcGIS 10.3.x).
  • ArcGIS API 3.7 for Flex and ArcGIS Viewer 3.7 for Flex are the final releases of these products.
  • ArcGIS Viewer 3.3 for Silverlight and the ArcGIS API 3.3 for Silverlight are the final releases of these products.
  • ArcGIS Runtime SDK 10.2.5 for WPF is the final release of this SDK.

For more information on our deprecation plans, refer to the following PDF document, Deprecation Plan for ArcGIS 10.3 and 10.2.x (this deprecation plan is also available at the following technical article in the Esri Support Knowledge Base).
Gregory L. - Online Support Resources

Filter Blog

By date: By tag: