Duplicates reviewer anomalies are not filtered for the same data in different versions

Question

Hi,

I'm working with data on an enterprise database.  My organizations authoritative data is stored and managed on an SDE and versioning is enabled.  As part of our workflow, any required edits to the SDE (e.g., additions, updates or deletions of the data) are performed through a version of the SDE (child of the parent SDE) and QCed before it is pushed up and posted to the SDE.  We are implementing Data Reviewer batch checks as part of our QC.  Often, we encounter errors that are exceptions and are marked as such.  Because of the time spent on investigating the errors, we would like for Data Reviewer not to reflag the same errors that we have already marked as an exception (i.e., filter out duplicates).  This does not appear to be a problem if we are working in same version that the error was produced under, but if I post my version edits to the SDE (the parent), and rerun the same batch checks in the parent version, the same error that was marked as an exception under the child version will flag again into the Reviewer table.  I understand this is because the duplicate filtering is based on several fields that include the Parameter field, which stores the database version the checks were run on.  How would I be able to exclude the version name in the parameters field or to exclude the parameters field all together in the filtering of duplicates so that the error doesn't again flag in either child or parent version.

AndrewVitale3 · Answer

Hello,

Did you find a workflow that suits your needs? I'm facing a similar issue, where we would like to be able to verify exceptions in child versions, and have Data Reviewer respect those exceptions in new child versions. Adding a new field to the authoritative data's schema to track exceptions is not an option for us.

Also, did you find a document that states how the duplicate filtering works in Data Reviewer, or is that just based on trial and error?

Thanks,

Andrew

JaimieChhu1 · Answer

Its a good work around, but it assumes that one will not be working in the same area again.  If I update or add new features to Area A and mark exceptions accordingly within Area A, I'd like those exceptions to be pushed up to the parent and be able to replicated to a second child version, so, should there be additional future edits in Area A or areas overlapping Area A, I can build another second child off of the parent and perform a QC of Area A (or area overlapping Area A), and I won't have to revisit the exceptions I previously marked within Area A under the first child.

StaleyB · Answer

I like the idea mentioned by Joe above where one could create a new attribute that says either yes or no to the exception. It is pretty easy to export the exception table and then join it to your main feature class. In addition, we are looking at a feature class that would display the exceptions spatially. If in a different review workspace one could turn on the exceptions layer and see that there is an exception. The main issue remaining is the amount of unresolved errors within your error table that could go unaddressed. That seems like it could get confusing. I am not 100% sure how to link these which is what your question is about. As a suggestion maybe you could add a SQL expression in the check to look at this new exception field and either show the error if the exception field is no and not show the error if the exception is yes. As a note we are in the versioned setup as well more similar to the 2nd option that Joe mentioned. We are using the most recent version of ArcMap as well as Data Reviewer.