Disconnected Mode Version Issue

[mpboyle]

We are testing out disconnected mode with Collector and it seems to work well except for one issue.  The version that gets created when downloading for disconnected mode will not delete when running the reconcile versions tool.  We will continually get an error that says the version can't be deleted because it has dependent child versions.  In order to delete the version, I either have to manually delete the version through the Geodatabase Administration or remove the affected rows in the sde_versions table.

A few notes...

1) When I run the reconcile versions tool, I'm using our admin account which can delete any version

2) This is a simple setup, with only the DEFAULT version and the disconnected version as a child off DEFAULT, see screenshot below.

3) Below is a screenshot of the sde_versions table after data has been synced at the end of the day and the downloaded data has been removed from the device.

I'm curious how to resolve this issue or if anyone has encountered the same problem...?  Is there some step I'm missing that should be part of our end-of-day workflow to weed out the disconnected version from being a parent to syncs?  Do I have to manually un-register the replica that gets created as part of the disconnected mode process?

Any ideas / thoughts / suggestions are appreciated!

Thanks!

[SamuelTompsett]

Hello Matthew,

Please refrain from deleting rows from the geodatabase directly in SQL Server. This can cause inconsistencies quickly.

Are the child versions discussed the SYNC_SEND versions in the screenshot? If so, those versions will be removed when the replica is unregistered from both parent and child geodatabases.

Hopefully that helps!

Sam

[mpboyle]

Samuel,

Trust me, I don't want to be messing with the sde tables in SQL Server, I'm just looking for solutions.

The child versions are the SYNC_SENDs as highlighted in above screenshot.

Is the only was to remove those by unregistering the replica?  Is there a way to automate this process?  For example, at the end of the day I'd like to be able to fire off a script that would reconcile and post any edits from a disconnected version and delete it after the edits are posted so the next day is a fresh start, however I haven't been able to find a way to unregister a replica, unless there's a tool I'm missing...?

Perhaps there's a better workflow that I'm not considering?  Are there recommended workflows for disconnected editing and reconciling and posted any edits?  We have a nightly script that will reconcile, post, and compress our production sde gdb and I'm wondering if the disconnected editing mode can be rolled into that process, but having the child versions hanging out there without unregistering the replica is a hang-up.

[SamuelTompsett]

Hello Matthew,

You can run the Delete Version GP tool in ArcMap to remove the SYNC_SEND versions, provided all the data is posted correctly. You will have to manually enter the SYNC_SEND name, exactly as it is in the database.

33146 - What are the SYNC_SEND and SYNC_RECEIVE versions in the versions table?

Stepping back a bit, is it necessary to remove these replica versions and unregister the replica each night? It wouldn't be necessary to do.

As long as the edits from the replica reconcile and post to the parent version/replica, it is perfectly fine for the replica versions to exist.

Sam

[mpboyle]

Sam,

Thanks for providing the link explaining the sync_send and sync_receive versions.

Keeping the version around is not a big deal, especially in this gdb we're working with since it's meant for only data collection.

Where I'm coming from...our production sde gdb has a nightly script that does the following: reconcile and post versions, delete versions once posted, analyze, compress gdb, rebuild indexes, analyze, recreate departmental edit versions.  We delete the versions once posted, so that when they are re-created after the compress, all departmental versions are on the same page starting the day.  Given this workflow, disconnected editing kind of throws a wrench into the process because the disconnected versions are children of departmental versions and since they are not deleted until the replica is unregistered, any departmental version will not get deleted because it'll have a child version (the disconnected version).

What are common workflows that you've seen or would recommend for disconnected editing?

[SamuelTompsett]

Hello Matthew,

In your nightly script, you could implement arcpy.DeleteVersion to remove the SYNC_SEND version before deleting the departmental version. I cant really describe a common workflow because the workflows are across the board. I see workflows from keeping versions anywhere from a few months to a year, or deleting them nightly.

ArcGIS Help 10.1

It would really depend on what you want at the end of the day. If you want the versions completely removed from the database nightly, you will need to use Delete Version (to remove replica versions) before deleting the departmental version.

FYI. Removing the SYNC_SEND version using Delete Version will break any existing replica. Make sure the data comes across, and you are okay with removing the replica.

Hopefully that helps!

Sam

[mpboyle]

Sam,

How would I be able to delete the sync_send versions using arcpy.DeleteVersion...?  Neither arcpy.da.ListVersions nor arcpy.ListVersions shows these as versions within the sde gdb, screenshot below.

[SamuelTompsett]

Matthew,

The SYNC_SEND versions would have to be called explicitly. I dont think you will be able to list them with the arcpy module. You could implement some SQL scripts (in python) to query the geodatabase tables and then return the SYNC_SEND version name. Then, pass that through the Delete Version syntax explicitly.

Here is how to query for SYNC_SEND versions.

37551 - Determine if there are orphaned replica system versions in the geodatabase

Call something like this through python:

select * from sde.sde_versions where name like '%SYNC%'

An ArcGIS Idea to implement a tool to Unregister replicas.

https://esri.secure.force.com/ideaView?id=087E00000004esJ&returnUrl=%2Fapex%2FideaList%3Fc%3D09a3000...

I would recommend testing your script in a development environment.

-Sam