This table is the sde.sde.SDE_states in our production database. For some reason we cannot seem to compress away those states. Ive kicked everyone off the database including myself so that all state locks will be released and then compress but they just wont go away! We compress nightly and always drop back to these same states. Its a 10.1 EGDB on SQL Server 2008R2 without the SDE application server. Is there anything I can do from SSMS instead of Catalog to solve this?
Solved! Go to Solution.
I was searching for something else and this knowledge base article came up. I had 6 hidden versions from old replications that were unregistered that are just sitting out there in sde.SDE_versions. Their dates and state_ids were the same as the ones in the sde.SDE_states that wouldn't compress away. I used the Delete Version tool to drop them from this table safely. I did it in reverse chronological order to on the versions create date on a whim because it seemed safest, compressed, and BOOM! errant states gone. I'm hoping this will resolve some other issues I've been having. Please back up your geodatabase before you do this in case something goes haywire. None of my users have noticed anything amiss on the client end since this was done last Friday.
The table below shows the comparison of the two tables. Rows in green are versions/replicas that are current, rows in red are versions/replicas that should have been dropped but weren't. You can see that while they still appeared in sde.SDE_versions they had already been removed from sde.GDB_ITEMS. Item ID is in the name of the replica version.
How many versions are there in that geodatabase?
Do you reconcile/post all versions, delete the Versions and then perform compress?
Do you have replicas in that geodatabase?
enterprise gis sdecompressdata managementsde administration
Try the same things manually and check if that makes any difference:
Synchronize replica-->Make sure there are no other users connected (If there are Server Services running, stop them as well)-->Perform a compress
Ok Ill try that early tomorrow morning. When I kick all users I am switching to refuse new connections so no one can get back on before Im done. There isnt a Server site on the production server but I can stop the ones on our publication and fail over machines.
Hi, we frequently have similar problems with compress mysteriously refusing to get rid of states, and mostly it's either state locks (through logged in users or services) or replica versions that don't show up in the GUI. What I find helpful: