topic Re: Versioning Lineage in Data Management Questions

Versioning Lineage

ChadFoster — Thu, 22 Mar 2012 14:35:46 GMT

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]

Re: Versioning Lineage

JonDeRose — Thu, 22 Mar 2012 15:51:06 GMT

cfoster15,

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

Do you have any replicas synchronize versions within this configuration?

- Jon

Re: Versioning Lineage

ChadFoster — Thu, 22 Mar 2012 15:53:47 GMT

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

We do not have any replicas synchronized within this configuration.

- Chad

Re: Versioning Lineage

JonDeRose — Thu, 22 Mar 2012 16:05:41 GMT

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

Re: Versioning Lineage

ChadFoster — Thu, 22 Mar 2012 17:20:33 GMT

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]

Re: Versioning Lineage

JonDeRose — Fri, 23 Mar 2012 15:49:16 GMT

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

Re: Versioning Lineage

ChadFoster — Wed, 28 Mar 2012 15:33:03 GMT

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]

Re: Versioning Lineage

DaveOrlando — Thu, 29 Mar 2012 15:34:29 GMT

.............. 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,

Re: Versioning Lineage

ChadFoster — Thu, 29 Mar 2012 16:10:43 GMT

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

Re: Versioning Lineage

KenCarrier — Fri, 06 Apr 2012 16:44:30 GMT

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.

Re: Versioning Lineage

Anonymous User — Wed, 04 Dec 2013 20:39:13 GMT

Hello! I know this response is quite late, but after observing similar behavior for a spell, I believe that the image Chad attached to the 03-22-2012 11:20 AM post actually does represent an ideal compression. Any version will "take" a state when it reconciles, and that state will forever be in-between sde.DEFAULT and state zero.

Chad's initial image shows uncompressed states that should have been compressed "out." I have posted SQL to find these states without GDBT tools here: http://forums.arcgis.com/threads/94514-Administer-SDE-without-Versioning-Lineage-Tree?p=349059#post349059

Re: Versioning Lineage

Anonymous User — Wed, 04 Dec 2013 20:39:45 GMT

Hello! I know this response is quite late, but after observing similar behavior for a spell, I believe that the image Chad attached to the 03-22-2012 11:20 AM post actually does represent an ideal compression. Any version will "take" a state when it reconciles, and that state will forever be in-between sde.DEFAULT and state zero.

Chad's initial image shows an uncompressed state (12409) that should have been compressed "out." I have posted SQL to find these states without GDBT tools here: http://forums.arcgis.com/threads/94514-Administer-SDE-without-Versioning-Lineage-Tree?p=349059#post349059