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

Remove Orphaned Records from Geodatabase

vijaybadugu

Hi, The Records are always stays in Delta tables and they are not removed from Delta tables after Compress.

We have a feature dataset with topology enabled with certain rules on it. Whenever we enabled topology on feature dataset, The feature dataset should be enabled as "Registered as versioned". The users are editing on SDE.Default version directly without creating any child version on it. Whenever we edit feature classes in that feature dataset, it created records in 'A' Table. I am doing daily compress or full compress. The records stays in 'A' Tables and not removed from delta tables. I unregistered all Replicas and tried. the issue is still the same. What I need to do for Full compress to remove all Orphaned records? I am using ArcGIS pro 2.8

and ArcGIS Enterprise 10.9

[SDE_compress_log]

[SDE_versions]

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

KathleenCrombez1

not sure if this will help you in your scenario, but i have found that all users (other than the administrator connection doing the compress) must be disconnected from the database in order for the records to be moved from the delta tables and pushed into the base tables when the compress is performed.

If any other users are still connected to the database it will only perform a partial compress and it will not push the delta tables to the base tables.

we do not edit in the sde.Default (each editor has it's own version). But i would suspect the compress would still act the same way. Not really sure though, because i assume you do not need to reconcile and post your edits when the edits are being done in the sde.default version.

vijaybadugu

I disconnected all users from geodatabase and uncheck the option. and did compress. still data exists in Delta tables

George_Thompson

Those versions in the table are related to the replicas. I wonder if they did not get cleaned up correctly. Here is a blog that talks about getting a fill compress; https://community.esri.com/t5/esri-technical-support-blog/tips-for-compressing-with-existing-geodatabase/ba-p/898380.

You may want to contact technical support and work with an analyst on getting this cleaned up.

Until those "sync_" versions are removed the edits will stay in the delta tables.

vijaybadugu

I created offline map for just read only mode and it is not meant for editing purpose. whenever user download the offline map to their devices, geodatabase creates a replica in the database. it doesn't go way until field crew deletes those maps from devices( not sure about it). we can't fully compress unless we delete these orphans records in sde_versions table and replicas those were created during this process. I was planning to write a python script to automate the entire process. I just have a question whether I'm right approach to achieve fully compress. I need your suggestions on it.

George_Thompson

if you know the names of the versions, you could use the Delete Versions tool and pass the names to remove.

That would help you get to the full compress.

vijaybadugu

Delete Versions tool doesn't identify these orphaned versions I tried that too.

MeghanBlair

Did you ever find a solution. I have the exact same thing happening. Orphaned replica versions which I can't delete with the Delete Versions GP tool because they don't come up as existing in ArcPro. But I can see them in SQL. I am tempted to delete the sync Recieve versions manually in SQL.

vijaybadugu

No. I have not found any solution and I am doing it manually.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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