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.
sde.SDE_versions | | sde.GDB_ITEMS |
name | state_id | ID | Replica Name |
DEFAULT | 205718 | | |
SYNC_SEND_3_0 | 0 | | |
SYNC_SEND_5910_1 | 118506 | | |
SYNC_SEND_7110_0 | 118621 | | |
SYNC_SEND_8312_1 | 118869 | | |
SYNC_SEND_8312_2 | 119777 | | |
SYNC_SEND_5910_2 | 163687 | | |
ParcelEditing | 205712 | | |
SYNC_SEND_20028_5 | 205591 | 20028 | - SDE.ProductionToPub
|
SYNC_SEND_19649_4 | 205591 | 19649 | - SDE.ProductionToFO
|
SYNC_SEND_9919_162 | 205591 | 9919 | - SDE.ProductionToROK
|
SYNC_SEND_18851_7 | 205591 | 18851 | - SDE.ParcelsToPub
|
SYNC_SEND_18848_11 | 205591 | 18848 | - SDE.ParcelsToFO
|
SYNC_SEND_20450_2 | 205718 | 20450 | - SDE.ProToFO_Supp1
|
SYNC_SEND_20453_1 | 205718 | 20453 | - SDE.ProToPub_Supp1
|