Trouble saving edits with SDE Checkout - vb.net

[Corbinde_Bruin]

Hello all,

I'm having trouble with saving to SDE checkout replicas in VB.NET.

Changes made to the relative replica (file geodatabase) through my Add-In software are not reflected when "Sychronize Changes" is run on the replica from the Distributed Geodatabase toolbar. My Add-In will add new records with attribute information, but edits to records that existed when the checkout was made do not show any edits after synchronizing changes.

I believe this has something to do with the SDE add/delete editing tables, but I don't really know much about that. I appreciate any input, pointers, links, or code samples. Thank you. I'm willing to post whatever code you think is relevant (e.g. StartEditing, SaveMethod, StopEditing).

I'm working in Desktop 10.2
ArcMap Add-In in VB.NET (using MS VS 2010)

Thank you,
Corbin de Bruin

[MichaelVolz]

Is there a setting (rule) that would tell the software to possibly keep the old database information instead of the new database information when editing data, as opposed to the scenario of adding a new record where there is no comparison between records needed which you say is working correctly?

[Corbinde_Bruin]

Is there a setting (rule) that would tell the software to possibly keep the old database information instead of the new database information when editing data, as opposed to the scenario of adding a new record where there is no comparison between records needed which you say is working correctly?

Hi Mike,

That setting is handled through the "Synchronize Changes" wizard in ArcMap, but I've tested this possibility and decided it is not the problem. I am not programmatically handling the setting you're describing.

I forgot to mention above that I can produce the correct result using the native editing tools in ArcMap and then proceeding through the "Synchronize Changes" wizard on the Distributed Geodatabase toolbar. I used that as a test to ensure that it was in fact my custom .NET Add-In that was causing me problems. And of course, it is absolutely necessary that I use the Add-In for my production work.

I now have an incident in with ESRI regarding the issue. It'll take a lot of time to get them a stripped down code sample that demonstrates my issue, but after I do I will be sure to post it here as well.

- Corbin de Bruin

[MichaelVolz]

Did you ever try to implement this process as an Add-In when you were using v10.1?  I ask, because I have found that processes that worked in v10.1 now have issues in v10.2 which need to be addressed by ESRI.  These items include changes to mapservice cache processing, multi-versioned views and uploading data to ArcGIS Online.

[Corbinde_Bruin]

I have not. We've completely migrated to 10.2 already so I sorely hope this is not the case. Testing that really isn't an option since we've also migrated our GIS server to 10.2 already. I don't think I have the ability to test on a 10.1 server.

- Corbin de Bruin

[MichaelVolz]

I know you work for a small company with limited resources, but you might think about using an EDN license for your upgraded GIS environment in the future to test for any bugs before taking the dive into the deep end of the pool.  This is a lower cost license you can get for development and testing.

[Corbinde_Bruin]

After further testing, I've found that my Add-In works perfectly with Personal Geodatabase checkout replicas. Only File Geodatabase checkout replicas are not showing edits when Synchronize Changes is run. This at least provides a workaround, but it is not the solution I was hoping for.

I am programmatically saving edits exactly the same way for both Personal and File Geodatabases. Am I supposed to be handling these two cases differently in code?

- Corbin de Bruin

[MichaelVolz]

I am programmatically saving edits exactly the same way for both Personal and File Geodatabases. Am I supposed to be handling these two cases differently in code?

I would not think there should be a difference if there is no dialog box with the manual method that would let the enduser choose the type of geodatabase they are using for their replication.

At this least I would log an incident with ESRI to see if they can duplicate this behavior in their environment, in which case if would be a bug that they would need to fix with a future service pack.

[Corbinde_Bruin]

At this least I would log an incident with ESRI to see if they can duplicate this behavior in their environment, in which case if would be a bug that they would need to fix with a future service pack.

I already have an incident in, and now I've published a sample Add-In project, sample geodatabase, sample MAp document, and a text file including detailed instructions on how to reproduce the unwanted behavior. All is in the attached zip file below. I will update further once the ESRI tech gets back to me.

[Corbinde_Bruin · Accepted solution]

Just a few days ago ESRI finished working on this incident after months of back and forth. They have decided it is a bug.

From ESRI Tech:

BugID: NIM097672

Synopsis: Synchronizing edits made by SEARCH CURSOR on existing features in a replica FILE GEODATABASE database with Arc Objects code are failing. After synchronization, only new features are posted on parent database, but no edits to EXISTING FEATURES are posted.

Workaround:
Synchronize the changes from ArcCatalog.

If the features are edited by update cursor then the edits are posted on the parent database.

- Corbin de Bruin