I hope that I've found the corner of the internet where Data Reviewer types like to hang out. If there is a better place, could you let me know? Thanks!
Solved! Go to Solution.
So we've been told that since the related tables have no spatial component, the tool is operating as planned by evaluating all records participating in the relationship. This makes it difficult to work with. However, despite this, the organization of the rules and a revision of our database design and continual reconciliation of replicas has increased the speed of the time required for Data Reviewer analysis. The checking of all relationships has caused us to use work arounds so as not to burden users. This is workable but doesn't lend itself to providing a truly efficient solution for Quality Control that we had hoped. Hopefully this issue will be resoled on further release.
I know this is a very late reply, but...
Brett, I'm not sure how one could expect a non-spatial table to be able to use Current Extent to reduce the number of records to evaluate. Current Extent is bounding box. Your data has no spatial component so your data has no relationship to the box. There's no way for Esri to resolve this in any release.
You need to get a spatial component into your data to take advantage of Current Extent.
Note that some checks, such as Unique ID discussed above, require a full database search to determine uniqueness. You can't determine uniqueness by examining only a subset of a database. I suppose one could argue the case for determining uniqueness only within current extent.
If you could join your data against a feature class with a spatial component then perhaps you could run a check against Current Extent without having to actually turn your data into a spatial table. I think Michelle would have to comment on if DR can run against a join.
DR does not work against fields in an ArcMap join. Something that would be nice to have though. Maybe something for ArcGIS Pro...
Depending on which option is being used in the Relationship check, I would think that the relationship check would work against the features in the current extent from the origin feature class, but would have to compare to all records in the destination feature class or table. For example, looking for orphan origin features should be able to honor the selection set and current extent options. If not, then sounds like a good enhancement! (jcary-esristaff)