Pro Reviewer Rules in a Map - change database edit version

[Steve_Salas]

I am attempting to replicate a method we used with Data Reviewer in ArcMap where we developed a Data Reviewer batch file (RBJ), and would then use that file to perform quality control against each editor's SDE/Enterprise geodatabase version prior to reconcile & post of the version.  I realize RBJs can be run in Pro, but they don't appear to have a long-term future https://community.esri.com/thread/244575-will-arcgis-pro-support-creating-data-reviewer-batch-jobs-i... 

I attempted to develop some ArcGIS Pro (2.5.1) Reviewer rules (against the SDE.Default version) saved in the map, then I saved the map (Share -> Save As Map File) to disk.  In the editor's ArcGIS Pro session, they import the map file (.mapx) from disk.  In this imported map, they change to their edit version and create the reviewer session in a FGDB, run the reviewer rules from the Manage Quality tab... and it appears to run against the SDE.Default version.  It did not associate their layers with those created in the reviewer rules.

I know in our ArcMap solution, I think there is something in our ArcObjects code that might handle this change of version/workspace (I didn't program that solution).

I'm curious if I'm even on the right path trying to use reviewer rules in this way...?  Or does there need to be some custom code written to achieve this with reviewer rules stored in a map?

Thanks for any ideas,

-S.

[KumarGaurav · Accepted solution]

Hi Steven,

The workflow that you used is correct for the scenario you mentioned. I quickly tested the same where you shared a Map File with editors and they are editing on their respective versions and then run the Reviewer Rules. However, when I executed my Map rules against the child version. I am getting expected results. Please see the video below:

Thanks,

Kumar

[Steve_Salas]

Sorry Kumar, just getting back to this.  I think part of the problem is that I was using the Domain check, and creating errors by changing from the approved upper-case domain code to lower case  ("C" is valid in the domain... "c" is not.)   My initial impression now is that the Domain check is not sensitive to case.  I'll test more next week and if that is the case, I will file a bug with Support.  Then I can go back to trying the rest of my workflow.   Ahhh, SQL Server not case sensitive.  That explains quite a bit...