Version scenarios: Concurrent editing of the published database

[giuseppeprocino]

Hi,
I have the following version scenario:
Concurrent editing of the published database as you can see (http://resources.arcgis.com/en/help/main/10.1/index.html#//003n000000rq000000) in a small company.

My version scenario has:
- only DEFAULT version with PUBLIC access (the owner is SDE).
and the users:
- SDE (default user and owner of DEFAULT version)
- Datacreator (he import all feature class)
- Dataeditor1 (he edit the feature class)
- Dataeditor2 (he edit the feature class)
- Dataeditor3 (he edit the feature class)

Now, the company workflow is:
1° datacreator import an feature class for ex. LandUse
2° datacreator register the feature class LandUse without options "Register the selected objects with the option to move edits to base."
3° dataeditor1, dataeditor2, dataeditor3 are connect to DEFAULT version and make editing on LandUse.
4° In this step the editing (make to previus step) are stored within Add and Delete tables.
5° If SDE user compress the db, the edits remain within Add and Delete tables.
6° If Datacreator press on "Unregister as versioned" on LandUse and check the options "Compress all edits in Default version into the base table." the edits are moved to base table.

My question is:
Is the step six the only method for move edits (within Add and Delete tables) to base table? All command on version toolbar are disabled with this type of configuration.

Tecnology:
- ArcSDE 10.1&Oracle11gr2&SDO_GEOMETRY&AGD 10.1 full patch

Regards
Giuseppe P.

[AsrujitSengupta]

No,  that is not the way for an effective compress.  You need to make sure that none of the editors are editing the data while you are running the compress.  I'll suggest that make sure no other users are connected to the Geodatabase when the compress is being run. Then check whether  the delta tables are flushed out to the base table or not.

However you did not mention how the data is published( map service,  feature service, etc). Just for testing,  stop the Services as well and run the compress.

You may be observing a partial compress and hence see some records staying back in the delta tables.have a look at the below link on how to achieve a full compress:
http://resources.arcgis.com/en/help/main/10.1/index.html#//003n000000s5000000

[WilliamCraft]

To get 'the most' out of a Compress operation, you must have accomplished the following:

• Reconciled and posted all edits from all child versions of your DEFAULT version such that the state IDs of those versions match the state ID of DEFAULT or the child versions are deleted after reconciling and posting. 


• Terminated all geodatabase connections, as Asrujit eluded to above (sometimes existing connections can put a lock on specific states and/or tables which prevents a full compress). 

If both of the above are accomplished, then in theory you can compress to State 0.

[giuseppeprocino]

Hi,
Asrujt your answer is correct.
There was some users connected. The compress is ok now and the delta table is empty.

Hi William ,
the point "Reconciled and posted all edits from all child versions of your DEFAULT version such that the state IDs of those versions match the state ID of DEFAULT or the child versions are deleted after reconciling and posting."
isn't applicable if I have DEFAULT versions only. There aren't child versions.

Thanks a lot
Giuseppe P.