Needing some help with ArcSDE Compress over Easter Weekend.
Until every recently, I've had a Python script doing SDE maintenance every night - a reconcile/post on all versions, followed by a compress. The database in question houses a number versioned feature classes that are manually edited throughout the day. No huge volumes, but constant change. Also, I have a variety of scheduled FME processes writing to versioned feature classes. This was all working. Then, suddenly I was seeing errors from the FME end about conflicts in reconciling and things started "escalating" from there. What I found was some "bad" data that was stuck delta tables - either as a result of some root cause or maybe the cause of it all ?
As remedy, I temporarily disabled some nightly ETL and my scheduled maintenance. Next, and I removed the unwanted records with:
exec dbo.set_current_version 'DBO.AdminWork'; exec dbo.edit_version 'DBO.AdminWork',1; DELETE FROM ... WHERE.... exec dbo.edit_version 'DBO.AdminWork',2;
Then I disconnected users, set the Allow-Connections to 'False', reconciled all versions, and ran a compress. I've tried this a couple of times ( keeping that infamous definition of insanity in mind), both through ArcCatalog as admin and using arcpy. Each time, I end up with something like this:
This state is associated with a number deletes in one D-table. But someone I seem to be unable to reconcile-post-compress them away.
I've used some queries for locks and related processes from this excellent topic. But I have found no locks, and by not allowing any processes to connect, I have to connections by the time I execute the compress.
So my question is: What could make those "deletes" persist and keep my versions from all getting back to state 0? (Now, I should note that I realize that usually not getting all versions to compress back to 0 is no reason to panic. But this all started when I was getting errors about conflicts during reconcile. Otherwise, I wouldn't have been poking around.) - Thanks for any clues! Happy Easter.