SDE issue - Metadata of Default changes when operating on Versions

[ChrisDonohue__GISP]

I'm running into an issue with Metadata and SDE.  I'm not an expert on SDE, so was wondering if folks had run into this, and if so, what they do to address it.

I recently created a Version and made some edits, then looked at the Default copy of the Feature Class and the Metadata for Default shows the changes I made to the Version!  These changes include both manual updates to the metadata and the automated geoprocessing updates to the metadata.

This is a bit disturbing, to say the least.  Default is supposed to be a static copy of your data.  However, any changes you make to your Version are immediately applied to the metadata of Default, resulting in mismatch of metadata and data.

Plus the metadata changed without a review - i.e. this happens immediately, not even waiting for a second-party review at the Reconcile and Post steps.  So file control and Data integrity are an issue.

I discussed this with ESRI Tech Support this morning and they say its a known issue since 2006.  Unfortunately, there is not currently a timeline to fix it, though it is already on their bug/enhancement list.

From what ESRI told me, the way Metadata is implemented in SDE is as a single file associated with the Default feature class.  However, unlike the data it documents, it cannot be Versioned.  So anytime anyone creates a Version, they are directly impacting the metadata.  And, of course, being that SDE is a multi-user database, think of the havoc of several people all working on a Version of the same feature class - the metadata is immediately getting altered by all the Versions.  In that situation, a user who accesses the Default feature class might find the metadata to be bizarrely mismatched to the data they are seeing.

In terms of workarounds, the metadata in SDE cannot be locked to prevent the changes.

So the reality is that when you work on a Version in SDE, you are changing the metadata for Default, whether you realize it or not.

So my questions are these:

- Has anyone else noticed this?

- Has anyone figured out a workaround to protect the Metadata from being altered until the Version is ready to be finalized (i.e. it was reviewed in Reconcile and Post and is now ready to replace Default)?

Chris Donohue, GISP

[ChrisDonohue__GISP]

An update from ESRI Tech support:

I have logged a new enhancement request, "ENH-000085041: Provide an option to record separate metadata with versioning in a multiuser geodatabase" Thank you for bringing this to our attention and for your help in troubleshooting. Our Software Developers will review this enhancement to determine further action to address this issue. For the most up-to-date information, please use MySupport at http://support.esri.com. Feel free to contact ESRI Support Services with further questions.

This would be a very welcome enhancement (though I'm sure it is easier said than done).

Chris Donohue, GISP

[forestknutsen1]

I have not noticed that in our SDE - but that sounds icky! So what is the suggested workflow for this? Do not do metadata editing in a version session? What happens if two people edit the default metadata version at the same time? Maybe they are trying to edit the same metadata field.... Publish date say.....

[ChrisDonohue__GISP]

Just to reiterated a very important point on this - while the feature class may be Versioned, according to ESRI there is no corresponding versioning of the metadata.  In other words, there only is ever one metadata file for a feature class, irregardless of how many versions are created.  The moment anyone manually types an entry into the metadata, it goes straight in.  As to what happens with two people simultaneously updating the metadata at exactly the same moment, I don't know for sure what happens.

ESRI suggested some workarounds for dealing with it as it is set up now:

1.  Don't do any manual metadata editing until just AFTER you Reconcile and Post.  Of course this leaves a gap where Default can be accessed and the metadata is not yet up to par for it.

2.  As for the automatic recording of the geoprocessing log, if you have ArcGIS 10.2 or newer, you can turn off its capture, which is helpful when testing different geoprocessing tools while trying to best resolve an issue when working on a Version.  To do so, go into the Geoprocessing Options and uncheck to box for "Log geoprocessing operations to a log file".  You have to remember to turn this on and off as appropriate, though, which could cause some issues.

3.  If you already have metadata that has been impacted by lots of extraneous geoprocessing information (stuff you tried but was not used in the final result of your version), it can be manually stripped out of the geoprocessing log by editing it in an xml editor.

Chris Donohue, GISP

[forestknutsen1]

Thanks for posting this Chris. Very informative.

[ChrisDonohue__GISP]

Another update:

ESRI suggested I post this on the "ArcGIS Ideas" site so people can vote and comment on it.  The ESRI Developers check the the site not only to find out what customers want, but to gauge how important these issues are.  So vote for this one (and others you think are a priority):

https://c.na9.visual.force.com/apex/ideaList?c=09a300000004xET&category=Geodatabase&sort=recent

Thanks,

Chris Donohue, GISP

[ChrisDonohue__GISP]

Update - I just realized the link I posted was incorrect to get one to the ESRI Ideas site.

Correct link:

Esri Arcgis Ideas | Ideas Submission Portal

Chris Donohue, GISP