Versioning Lineage

[ChadFoster]

We set up a versioning tree in sde with sde.DEFAULT and QA/QC as a child and then created separate versions for two employees with QA/QC as the parent.  Another user, my boss, somehow created a version that seemed to be above the sde.DEFAULT when looking a the versioning lineage tree.  Both employees have posted and reconciled up to sde.DEFAULT, deleted their versions, and have run an analyze - compress - analyze.  We also deleted the version our boss created after verifying that he made no edits on that version.  We are now left with a versioning lineage (see attachment).  Is this ok?  If not, how can we get our lineage tree with the sde.DEFAULT back to the zero state?
[ATTACH=CONFIG]12933[/ATTACH]

[JonDeRose]

cfoster15,

Have you run a compress following the deletion of your boss' version?

Do you have any replicas synchronize versions within this configuration?

-  Jon

[ChadFoster]

Yes we have run a compress following the deletion of that version.

We do not have any replicas synchronized within this configuration.

- Chad

[JonDeRose]

Chad -

Following removal of the versions and running of compress these states should have been truncated and SDE.DEFAULT should point to 0.  Do you have any orphaned state_locks within your ArcSDE repository?

I would recommend contacting Technical Support with your full system configuration as well as a screenshot of your sde.versions table to investigate this further.


- Jon

[ChadFoster]

We did have a couple of locks that were caused by map services, so we stopped all map services and made sure their were no locks and then ran an analyze - compress - analyze again.  We are getting closer (please see attachment) but still not what I think it should look like.
[ATTACH=CONFIG]12936[/ATTACH]

[JonDeRose]

Hi Chad,

Could you provide a screenshot of your sde.versions, sde.mv_tables_modified, sde.state_lineages, and sde.compress_log for review.  The usual reason for behavior such as this is locks, edit connections, orphaned states, or replicas in need of synchronization.  If none of these appear to be leading to this behavior we would need to investigate this further.

You can also call Esri Technical Support with this information as well and they should be able to assist you rather quickly through a series of tests.

- Jon

[ChadFoster]

I am enclosing screenshots of all the tables you requested, thanks for looking into this.

Chad


[ATTACH=CONFIG]13080[/ATTACH][ATTACH=CONFIG]13081[/ATTACH][ATTACH=CONFIG]13082[/ATTACH][ATTACH=CONFIG]13083[/ATTACH][ATTACH=CONFIG]13084[/ATTACH]

[DaveOrlando]

.............. on a side note, how did you produce the lineage tree diagram? I have not come across this tool, or did you just make it manually from what you saw in your tables?

10.0.3

Thanks,

[ChadFoster · Accepted solution]

D.Orlando,

After some research on the forums, I came across a thread discussing the GDBT.
I am providing the link to that thread below.

Geodatabase Toolset (GDBT) for ArcGIS v.10

Hope this helps...

Chad

[KenCarrier]

Just because you delete that particular version does not mean all other lineages will get cleaned up.

Full compress
1. Disconnect all users including Server
2. Rec and Post
3. Compress
4. Delete all versions not just one
5. Compress
6. ReCreate Versions

run this sql statement in your rdbms interface

select state_id from states;

should = 0

or just look at the table in ArcCatalog

A Full compress is dependent on no locks and running a compress after deleting the versions in my experience.