Reconcile version error

[Geospatial_DS]

Our organization created QAQC version with DBO owner under SDE.Default and under QAQC we have 9 different versions also with DBO owner. I am told that previously all the Reconcile and Post process was working fine. Currently, I am given responsibility to perform Reconcile and Post. When I started Reconcile and Post process, 2 versions (out of 9) are giving below errors while Reconciling. I checked the feature class "GDBPROD.DBO.PE_Mets" but it has not field/column name "PEW_ID". In addition, I checked field/column name "PEW_ID" in QAQC and SDE.Default versions feature classes and no one have "PEW_ID". We are using SDE.Default version data for integration with other systems and due to this latest data is not available in integration systems.
----Error message-----------
The version could not be reconciled.
Attribute column not found [42522]:[Microsoft][SQL Server Native Client
11.0][SQL Server]Invalid column name 'PEW_ID',]
[GDBPROD.DBO.PE_Meters]
----------------------------
When I run again Reconcile operation then some time below error (with additional last line error that "The workspace is not connected");
----Again Error message-----------
The version could not be reconciled.
Attribute column not found [42522]:[Microsoft][SQL Server Native Client
11.0][SQL Server]Invalid column name 'PEW_ID',]
[GDBPROD.DBO.PE_Mets]
The workspace is not connected
----------------------------
We are using Microsoft Windows Server 2012 R Standard, Microsoft SQL Server 2008 R2 Standard, Enterprise Geodatabase 10.2.1 and ArcGIS Desktop 10.2.1
I searched for these errors on ESRI community and other sources but did not find similar errors or solution reported by anyone.
I would really appreciate some guidance. Thanks

[AndrewFarrar]

Just a shot in the dark, but it seems like you only mention checking GDBPROD.DBO.PE_Mets for the column PEW_ID. However, the errors are referring to two different feature datasets, the first being GDBPROD.DBO.PE_Meters. Have you tried checking versions of the PE_Meters datasets for that column name as well?

[Geospatial_DS]

Thanks a lot Andrew, actually both feature classes name in error is GDBPROD.DBO.PE_Mets and its writing mistake. I checked all the related versions but did not find PEW_ID column. May be I am missing some thing. For the time being, I am thinking to backup all feature classes of QAQC version (as it has latest data) to File Godatabase and then delete all feature classes data in SDE.Default version and after that load File Geodatabse all feature classes data (using Load Data tool) to SDE.Default version. Final step would be to delete all 9 versions and QAQC version and compress/analyze the Geodatabase.This workflow would take long time.

Is this right worflow or is there any other better workaround?

[BillFox]

It sounds like versioning is getting dizzy and needs to be better isolated

I think you will need to make DEFAULT "Protected"

Then create "Public Posting" versions for each editor

Then each editor create their "Private" editing versions

[Geospatial_DS]

Dear Bill Fox, we are following the same workflow.

Is there any better workflow in our current scenario to post the QAQC version data to DEFAULT version as a I described in above post?

[BillFox · Accepted solution]

Yes, I have seen that type of strange behavior before when having multiple editors reconciling & posting to the same parent version.

The way out is for you to create a separate public "Posting Version" for each editor.

Example:

1) DEFAULT (Protected) > Post_WalterQ (Public) (created and owned by an account you control) > WalterQ (Private, the user creates off of their assigned "Posting Version".

2) DEFAULT (Protected) > Post_TommyV (Public) (created and owned by an account you control) > TommyV (Private, the user creates off of their assigned "Posting Version".

3) DEFAULT (Protected) > Post_FrankQ (Public) (created and owned by an account you control) > FrankQ (Private, the user creates off of their assigned "Posting Version".

This isolates each editor from hitting a single parent posting version and making it dizzy.

Then you have a Windows scheduled task that runs the reconcile and post tool from all the "Posting" versions to DEFAULT.

(A note about the "Typical" weekly routine)

We have that scheduled task set to run each 30 minutes throughout the day.

The editors are responsible for their edits, quality control, etc.

So, as soon as they are comfortable reconciling & posting to their assigned posting version the next run of that task puts the changes into DEFAULT for all to see and use.

We have a weekly maintenance window on Thursdays at 16:00 - 18:00 when we can do a state zero and other chores.

The editors know they are free to work in their private editing versions during the week but must reconcile and post before Thursday at 16:00 or loose their work when all the versions are deleted and recreated during maintenance (a few other simple python scripts).

Friday mornings the editors create their private editing version off their posting version and around we go again for the next week.

[Geospatial_DS · Accepted solution]

Thanks a lot for valuable feedback and better workflow. Logically it seems very good. I would implement this after consolidation of existing data to Default version.