Collector impact on geodatabase compress operation

[NicolasGIS]

Hello,

Here is a long post about the Collector impact on geodatabase compress operation.

Problem :

I noticed that the compress operation is not working as expected because of Collector replica/versions I believe

Context:

We have set up a while ago some Collector applications for data collection.
Though these webmaps are used to collect some data, another goal of these applications is also to have many layers (#30) as read only to help decision making on the field (offline functionnality).

The read-only data is hosted in an ArcSDE Oracle database and versionned and the web map is referencing ArcGIS Server 10.5.1 feature services with sync functionnality enabled.
There is only one version in the read only database : the DEFAULT one (basically we enabled versionning for Collector).

Observations:

Everything has been working fine, but now that these applications have been out for a while I noticed that the delta tables are growing and compress operation removes only few STATES.
I do not have much experience with database replications and versionning other than with Collector so maybe I missed something...

I believed for a while that some Collector applications had not been synchronised for a very long time and were preventing the compress from compressing, but when doing some tests, I noticed that when I download the map and 2 days later I synchronized (some data in the read only database have been updated in the meantime), while looking at the SDE.VERSIONS table, I see that new versions are created (SYNC_(SEND/RECEIVE/RECEIVE_REC)_REPLICAOBJECTID_X) with X becoming bigger but all the versions still reference the original STATE_ID of the initial download.
I would have thought that it would have come back to the last STATE_ID of the database and thus a compress would then be effectiv has nothing would reference old STATE anymore.

Questions:

Does that mean that synchronizing is not enough and that I have to ask the user to download again the map once in a while rather than synchronizing if I want the database to be compressed ?
Or are there any operations that should be done on my side ?
Are they other people facing compress problems because of Collector ? Any advices, hints ?

Thanks for your help,

Nicolas

[NicolasGIS]

Digging a little bit further I found that interesting script that seems to answer my question:

Automate reconcile and post operations for sync-enabled data—ArcGIS Help | ArcGIS Desktop 

The thing which is funny is that the function:

arcpy.da.ListVersions('//connectionLocation/admin.sde')

returns only versions that were created few weeks ago since we migrated the ArcGIS Server from 10.4.1 to 10.5.1.

The returned versions follow the pattern : "username_AGSFolderService/_TIMESTAMP" and are the only one "Private", all the others are "Protected", follow the pattern SYNC_(SEND/RECEIVE/RECEIVE_REC)_REPLICAOBJECTID_X and are not visible in ArcMap even with an SDE connection.

This is a big change : on 10.4.1, when synchronizing, without any version management operation (reconcile, post), all the changes on DEFAULT where sent to the replica. Now, on 10.5.1 it is not case : reconcile/post must be done on the private versions.

I checked the 10.5.1 new features list but did not find anything about replica management. Does that ring a bell to anybody ?

[AxinGlobal]

Hey Nicolas Guilhaudin, 

I seem to be having similar issues I wonder if this is a bug that needs to be reported? 

In any case how were you able to reconcile/post the private SYNC/REPLICA versions? Did you use the 'Delete versions that are no longer referenced by a replica' script from the link above to instead delete the versions? Would love to hear some more detail on the process you used to manage these lingering private versions. 

Thanks 

Hamish