We have had for years, no decades, an ArcObjects-based .NET process that reconciles outstanding versions. When reconciles are complete, a compress is initiated. This (at least until now) has run like clockwork.
A few weeks ago users discovered that versions not reconciled and posted during the day, which most are, were found to have corrupt network features when the version was re-opened the following day. And when I say "corrupt" I mean either not connected to other features or un-editable -- and requiring the "Geometric Network Editing" tools to repair.
After investigation we found that if we turn off the nightly reconcile (basically disable the scheduled task under which it runs) features are not corrupted.
Clearly something has changed and we're in the process of trying to determine what. In the mean time we've found that an ArcPython scripted reconcile does not seem to cause corruption. However, the fact that something so fundamental to our solution is failing is a cause for concern. Any chance anyone else has seen this? If so, any feedback would be much appreciated.
Thx,
Ed
