state_id ownercreation_timeclosing_timeparent_state_idlineage_name0sde2010-03-29 14:59:50.0002010-03-29 14:59:50.00000118506"BAY\KMCDONALD"2013-12-03 15:42:41.0302013-12-03 15:43:32.8830118229118621"BAY\DCOLE"2013-12-13 10:43:42.2002013-12-13 10:43:44.273118506118229118869"BAY\JDOMICO"2014-01-02 07:57:54.9672014-01-02 07:57:55.583118621118229119777"BAY\JDOMICO"2014-01-28 09:25:56.3502014-01-28 09:26:03.150118869119772163687SDE2014-06-12 10:06:57.2432014-06-12 10:10:43.783119777163687163705"BAY\GISINTERN"2014-06-12 10:19:07.5232014-06-12 10:19:07.593163687163687169619"BAY\CMATHERS"2014-07-01 08:00:01.8732014-07-01 08:00:10.057163705169546185464"BAY\DCOLE"2014-08-21 15:48:49.3202014-08-21 15:52:17.930169619185415187638"BAY\DCOLE"2014-08-27 16:00:03.0602014-08-27 16:00:06.247185464187554191938 "BAY\JDOMICO"2014-09-17 15:52:26.2102014-09-17 15:52:35.060187638191826 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?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Find more posts tagged with

Accepted answers

ChrisMathers

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

All comments

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.

JuanOrozco

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

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.

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-for-10-0/
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

MartinAmeskamp

Great, this is very helpful!

Martin

Von: Asrujit SenGupta

Gesendet: Montag, 22. September 2014 10:42

An: Ameskamp, Dr. Martin

Betreff: Re: - Enterprise geodatabase states will not compress.

GeoNet <http://jiveon.jivesoftware.com/wf/click?upn=Dg1s4x8le7Lmxv8KWGaqo8h7SGfRSMkw-2FpvHGF9-2FW3rK-2Bvs1kL9-2FnG6jjf2NZhrLDz0M-2BrY-2By9IaziQEKVk3Hg-3D-3D_GjRFCNGdMNqdt7rSVIqdH0qHqDDgIeyIXpkS4jn6U-2Fr3fh9mo7Hp47Cmfn-2FKfkYVPSbbPhU0zRTPicqVCMlD7FbwMUYhqnW58oFK-2FGfuLhjFbREYhbLeVp97-2B4OPuop5QgN17AAVrl2OKR7ZLJc3RRKwoiuyXv-2FDV3ASGHdfGW1rb8EUJLWA0ge16kurRh3X5J-2BAFJAmD-2FBolms5qX8vH8UxKou0BP2ubOOT3yZiHq2RRYAJHAGjPZPlgAqZZ61E6-2Fulolax4O736Itd6vVxEPHFR4fN69r1gBJk8gjVR1pLorcDiIpehvZu-2BjDl-2B9THY8ed4MMtHstfZ67Wd0FUqA-3D-3D>

Enterprise geodatabase states will not compress.

reply from Asrujit SenGupta<http://jiveon.jivesoftware.com/wf/click?upn=Dg1s4x8le7Lmxv8KWGaqo7A4BXwO9PY1WvQ5cXCtK48Jctg75Ycpj-2BRd4g0XdHaw-2FhL5Iztn268OrIjUiJNX1xN5Fi76SF6y469H2YweiWWwsEST8EAvfskpoJIOD98-2B_GjRFCNGdMNqdt7rSVIqdH0qHqDDgIeyIXpkS4jn6U-2Fr3fh9mo7Hp47Cmfn-2FKfkYVPSbbPhU0zRTPicqVCMlD7FbwMUYhqnW58oFK-2FGfuLhjFbREYhbLeVp97-2B4OPuop5QgN17AAVrl2OKR7ZLJc3RfBfkAYzmWn1F2y3DmROOaxyiRlKG71G-2FqdMlIdqArgCdM5RkZLF7iNjsm8xBVQvtoC1SBoSSq5L7iDF7IMfAER5O7ybk79-2F0ehG5oRj3-2FCRMrViSbvEW2CaqGge267FEdOpIr4qRfkE56H0B459fGAybcHh0ob3FW8FjOCHpYUvIBufNPGyX0bNMGfcPxjFoQ-3D-3D> in Chris Mathers - View the full discussion<http://jiveon.jivesoftware.com/wf/click?upn=Dg1s4x8le7Lmxv8KWGaqo0VQjeJBYpG9HGC8QZBT-2FEycHS0jXhbpD4TgIoOkWpQ-2BwpTkmy8L6-2BlAImfOIYLQqJQ-2FFx4hDR4Z9w1V60v0bAI-3D_GjRFCNGdMNqdt7rSVIqdH0qHqDDgIeyIXpkS4jn6U-2Fr3fh9mo7Hp47Cmfn-2FKfkYVPSbbPhU0zRTPicqVCMlD7FbwMUYhqnW58oFK-2FGfuLhjFbREYhbLeVp97-2B4OPuop5QgN17AAVrl2OKR7ZLJc3RcRmHbT838tUZDOoRm0Z7msSkejIofGMULr8jd9fj2ch0wIzP9KM Z69fNIrZiluS4HwELiyiDZUtAAX2gCAXo9hDYWEd-2B12IBmuve0YCD5zy936SyK3avB2Q0mzZQ0bWwzer360wj9-2BORK3-2FIe83TRUImVR7rvIRe6g9z-2Bl1ftk2vhc70wa3L5qE-2BxXtNIRRag-3D-3D>

ChrisMathers

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

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.