I've inherited an older versioned enterprise geodatabase (ver 10.1 sql server 2014). Version tree looks something like this:
Editor1, Editor2, Editor3..... EditorN
The work flow is every editor reconciles and posts to the intermediate version, and then the admin reconciles and posts the intermediate version to default.
One editor, has problems reconciling and posting with the intermediate version: he gets the spinning wheel of no return. If I try to reconcile an post his version as the SDE user and the reconcile versions interface, I get the spinning wheel of no return. I've even tried to script it, but the only difference is I don't see the spinning wheel of no return, but the Spyder console just sits there.
There are times when it'll go right through. If/when that happens, I'm golden until the next time. But.... What can this guy be doing that is different from the other editors? All the others seem to reconcile and post with the intermediate version without a problem.
The best way to find out what is happening here is to setup and run an SDE Intercept to look and see where the hanging in occurring.
What you'll need to do once this is setup is run a reconcile of this problem version and compare it to a reconcile of a version that works fine. What you are looking for is the command that is occurring while or just before the hang occurs. This may be able to help you identify what the software is trying to do when it hangs. Tech Support can assist with this as well if you'd like to create a new case with them.
I'd also check the following:
Let me know if you have any questions.
Thanks Jonathan- I have a case open with Tech Support; I submitted the intercept log file over a week ago and still waiting to hear what it told us.
What we have found that works for this guy is to kick everyone else out, reconcile and post problem child and then let everyone back on. I have a script that includes that procedure (reconciles and posts a;and also compresses, analyzes, deletes and recreates all the versions; see Use Python scripting to batch reconcile and post versions—ArcGIS Help | ArcGIS Desktop ). Just waiting for the thumbs up from the agency suits. Hopefully once it's automated this problem goes away...
(ps: are you the Jonathan I've been working with on topology errors?)
Yep, you and I worked together on that topology case.
And, we recommend disconnecting all users and blocking new connections for a scripted rec, post, and compress process. So if it works that way, it would be the way we'd recommend to do it anyway. That being said, you should still be able to reconcile a version with users connected to the geodatabase but ideally they aren't using that same version you are trying to reconcile.
I see the case you mentioned. It looks like that analyst has responded asking for a trace. Send them another round of intercepts that match up with the trace. This way, if they look at your intercept and see something interesting that happens at a certain time, they can look to the trace and see what is happening at that same time from the DB side. This is the way I'd ask you to do it.
That being said, you should still be able to reconcile a version with users connected to the geodatabase but ideally they aren't using that same version you are trying to reconcile.
That's what is weird about this one guy: all the other editors can reconcile and post their respective versions through out the day. He can... Sometimes. But he gets hung up on something.
I modified the ESRI script referenced above such that after the editor versions get reconciled and posted to the intermediate, they are deleted. Same goes for the intermediate version once it's reconciled and posted. At the end of the script, I re-create them all.
I'll take a look at the case through my esri: I haven't been getting customer care emails (https://community.esri.com/thread/222574-customercare-esri-dot-com ) but I should be getting the now.
For us, it was that some editors have editing privileges to different layers and trying to reconcile & post to a common posting version would choke if the timing was just right.
To get past those weird issues we had to isolate each editor with their own (public) posting version off of Default.
Then they create their own (private) editor version off their posting version.
PostJoeA (Public verison)
JoeA (Private editing version)
That keeps them from stepping on each other in reconcile & post.
The windows scheduled task as admin to reconcile/post/compress from their posting versions to Default stopped hanging too.
Can you get to state zero regularly? No orphan records/locks?
Bill- all the individual edit versions are public as is the intermediate version they are all spawned from; as mentioned, my team inherited all this, and I question many of the methods deployed in our inheritance.
This egdb hadn't been compressed for years before we got it: there were literally tens of thousands of states. We now compress to 2 states, which I'm very happy with. I had a blocking version the other day and deleted it, but I still couldn't get the problem child to reconcile and post until we kicked all the others off.
Have you simply tried deleting and recreating a new Version for that editor and checked if the issue still occurs?
I would recommend, disconnect all users > do a full Reconcile\Post of all versions > delete ALL versions > do a full compress > recreate the necessary versions > observe the workflow, if that is possible.
I have deleted the problem child and recreated him; as mentioned above, my modified script reconciles, and deletes each version. I have to jump through a hoop or two for the governance board to approve my method, but once that's done, I'm confident things will improve. This particular system has a number of issues; reconciling and posting is only one...