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; } } }

ArcGIS Pro Enterprise 10.9.1: Compressing an enterprise geodatabase (SQL Server) fails to transfer the content of delta table into the base table,

JamalNUMAN

I have already posted this issue in the past but got no root solution.

Not sure why compressing an enterprise geodatabase (SQL Server) fails to transfer the content of delta tables (Add\delete) into the base table. I expect that the delta tables should get blank while all edits are transferred to the base table

What could be the issue here?

タグ付きの投稿をもっと見る

Accepted answers

All comments

MikeVolz

Are you compressing the database to state 0? I believe there are multiple ways to compress a database, but to ensure that all adds and deletes are moved to the base table, you need to ensure the database is compressed to state 0.

Review your states table and look for other community posts on this subject.

JamalNUMAN

Correct. I wanted to compress the geodatabase to state 0

MikeVolz

Here are some links to review that might be helpful:

Most applicable I believe - https://community.esri.com/t5/data-management-questions/enterprise-geodatabase-states-will-not-compress/m-p/630106#M35587

https://community.esri.com/t5/esri-technical-support-blog/tips-for-compressing-with-existing-geodatabase/ba-p/898380

https://community.esri.com/t5/geodatabase-questions/failed-to-compress-the-database-error-999999/m-p/1034470#M7018

JamalNUMAN

I went through several documents related to compressing but didn’t find what I’m encountered in.

In the screenshots of my first post, there is a difference between the number of records of the attribute table of the feature class and its corresponding the base table despite the fact that the compress tool is performed.

How to get them (the attribute table of the feature class and its corresponding base table) identical in terms of number of records?

Ne versions are there as per the second screenshot

George_Thompson

What does your dbo.versions table look like?

There must be something pinning the state. Have you run the reconcile / post tool yet?

Are you only editing in dbo.DEFAULT version?

Are there any locks on the tables?

JamalNUMAN

Have you run the reconcile / post tool yet?

No, as I don’t have versions

Are you only editing in dbo.DEFAULT version?

Correct

Are there any locks on the tables?

George_Thompson

What is in the dbo.versions table in SSMS?

Something is blocking the full compress.

JamalNUMAN

Here you go a screenshot for the version

George_Thompson

Ok, thanks. You should be able to get a full compress.

Not sure why it is not happening.

JamalNUMAN

I think the issue can be replicated easily as I tried it several times from scratch but I got the same result. After performing the “compress”, the number of records of base table doesn’t match their corresponding attribute table of the feature class

George_Thompson

If you have a repro case, I would log a case with tech support to investigate and report back to development, if appropriate.

JamalNUMAN

I referred to other threads and found out that we need three tools in order to match the attribute table with its base table; they are “compress”, “rebuild index” and “analyze dataset”. The model needs to run twice to get them identical (attribute table + base table)

Not sure what’s the secret here!

George_Thompson

I am not sure how rebuild indexes and analyze datasets would prevent the compress from happening. That is weird.

Glad to know that running the tool twice fixed it but should not take 2 times.

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

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