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

[JaimieChhu1]

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.

[JoeBorgione]

I don't have an answer, but a question;  if you've already QC'd the data at the lower lower level version, why are you running it again on the upper level version?  

It appears to me that you may have what I would call 'cascading versions'.  Something that looks like this:

sde.default

       |

version1

       |

version2

       |

versionN...

And you have different actions performed by different individuals at each version level.  If that is the case, and you are sold on the data-reviewer, would it make sense to add a field called QA_Exception and update it once and only once somehwere in the QC cycle prior to reconcile and post?

Or, perhaps your model could instead look like this:

                                 sde.default

                                          |

                     version1   version2   versionN...

That way you would QC each version, and sde.default would then be free of any duplicates upon reconcilation and posting.  On the flip side, if a change is made at version1on a given feature and it's QC'd reconciled and posted, and another change is made to the same feature at Version2, and it's QC'd, reconciled and posted, you will get a conflict that needs to be resolved.

[JaimieChhu1]

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.  

[AndrewVitale3]

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

[StaleyB]

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.