Conflicts detected for deleted features on reconcile

[JohnFannon]

Hi

We have a customer who is increasingly reporting (since upgrading from 9.3.1 to 10.2.1 a year ago) that they are getting conflicts when reconciling versions. The conflicts reported are always related to deleted features in the edit version (see below example). 

The customer has a relatively small team and there are only approx 6 versions open at any time. Edit versions are created from SDE.default and this particular case, no other users/versions have modified the objects in question since the the version was created, so the deletes should not be causing conflicts. Also, other similar deletes in the same version have reconciled without conflicts and I have tried to reproduce the same issue by performing similar edits in a new version, but do not get the same issues.

I have tried looking at the sde_states and sde_state_lineages tables, as well as the _A and _D tables for the feature classes and can't see any obvious issues or differences between the conflicting objects and those that reconcile ok. However, I'm certainly not an expert in this area.

Does anyone have an idea what might be causing the conflicts? Is there another scenario, other than a change to the objects in the default version since the edit version was created, that would cause a conflict?

The feature classes involved are all part of a geometric network, could this be part of the problem?

Does anyone have some useful SQL queries that I can run to investigate the state tree for this version or reproduce the queries that the reconcile tool is performing to detect the conflicts?

Any thoughts or assistance would be much appreciated.

Note the customer is using:

ArcGIS Desktop 10.2.1 (with the utilities and telecoms update 3 patch)

SQL Server 2012 / SDE 10.2.1 (with the utilities and telecoms update 3 patch)

Cheers

John

[VinceAngelo]

These sort of repeating non-reproducible issues should really be tackled in a Tech Support incident.  Often a snapshot of the database is required to unravel what is wrong.

- V

[JohnFannon]

Unfortunately, our recent experience with Esri UK support is that they will take up to a week to assign it to somebody, then if they are unable to reproduce it themselves, they will blame it on the 'environment' and not send it on to Redlands for proper investigation. They are also likely to suggest that the customer upgrades to the latest version, which is never a practical solution for an enterprise customer.

In order to provide a better experience for our customer, I am therefore looking to avoid all of that if possible by identifying exactly the cause of the issue and the method to reproduce it before raising it with Esri UK support. Hopefully then it has a good chance of being passed on to Redlands.

[VinceAngelo]

I understand the reluctance to go to Tech Support without your problem quantified (I just spent a month getting an ArcObjects Java bug entered), but waiting days/weeks to get into the queue won't make your experience faster. Far better to start the process, with the hope that it's a known issue, than to burn more time trying to come up with a solution, then start the clock ticking. 

Even though some Esri folks are active here in GeoNet, many are not, and this is a user interaction framework (with likely the same, or worse, interaction ratio). If you're not getting what you need from local Tech Support, you have at least two better mechanisms:

1. Talk with your marketing rep to help grease the skids (they'd need to be on board to get a QFE build for a non-terminal ArcGIS release anyway)
2. Talk with Esri corporate HQ in Redlands

There really isn't much anyone here can do with this class of problem, so placing GeoNet on your critical path to resolution isn't likely to improve your Support experience.

- V