Enterprise geodatabase states will not compress.

[ChrisMathers]

state_id	owner	creation_time	closing_time	parent_state_id	lineage_name
0	sde	2010-03-29 14:59:50.000	2010-03-29 14:59:50.000	0	0
118506	"BAY\KMCDONALD"	2013-12-03 15:42:41.030	2013-12-03 15:43:32.883	0	118229
118621	"BAY\DCOLE"	2013-12-13 10:43:42.200	2013-12-13 10:43:44.273	118506	118229
118869	"BAY\JDOMICO"	2014-01-02 07:57:54.967	2014-01-02 07:57:55.583	118621	118229
119777	"BAY\JDOMICO"	2014-01-28 09:25:56.350	2014-01-28 09:26:03.150	118869	119772
163687	SDE	2014-06-12 10:06:57.243	2014-06-12 10:10:43.783	119777	163687
163705	"BAY\GISINTERN"	2014-06-12 10:19:07.523	2014-06-12 10:19:07.593	163687	163687
169619	"BAY\CMATHERS"	2014-07-01 08:00:01.873	2014-07-01 08:00:10.057	163705	169546
185464	"BAY\DCOLE"	2014-08-21 15:48:49.320	2014-08-21 15:52:17.930	169619	185415
187638	"BAY\DCOLE"	2014-08-27 16:00:03.060	2014-08-27 16:00:06.247	185464	187554
191938	"BAY\JDOMICO"	2014-09-17 15:52:26.210	2014-09-17 15:52:35.060	187638	191826

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?

[AsrujitSengupta]

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 sde‌compress‌data management‌sde administration‌

Managing Data‌ Geodatabase‌ Move this thread to any of these groups for better response.

[ChrisMathers]

We have very few editors here so all edits are done to the base version,

We do have replicas, all one-way going out from this database.

[AsrujitSengupta]

Have the replicas been synchronized before compressing?

[ChrisMathers]

Yes. A script runs nightly that syncs all of the replicas and then compresses and runs stats on the geodatabase.

[AsrujitSengupta]

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

[JuanOrozco]

I agree with Asrujit. We always delete versions before compressing, otherwise we get this error. Give it a try.

[ChrisMathers]

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.

[MartinAmeskamp]

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:

• Look for replica versions in SDE.VERSIONS - these version have a flag set that hides them in the GUI. This is a bit easier and a lot faster than looking for replicas in ArcCatalog.
• Look at the state/version tree with the Geodatabase Toolset (GDBT). It's a bit dated and doesn't seem to be available for 10.1, but maybe you have a 10.0 client somewhere or can set up a VM for this? It might be worth the effort. Find it here: http://blogs.esri.com/esri/arcgis/2011/01/27/geodatabase-toolset-gdbt-for-arccatalog-now-available-f...
• Finally, theres a very helpful white paper on versioning and replicas: http://support.esri.com/en/knowledgebase/whitepapers/view/productid/19/metaid/1603

Martin

[AsrujitSengupta]

Martin Ameskamp‌ just in case you would like to get the GDBT working with 10.1 or later release

Using our favourite GDBT toolset with Desktop 10.1 or later release