I've been using ArcGIS Desktop Attribute Assistant to augment address management for 911 data that I maintain for our county and the local PSAP. I finally devoted some time to porting the rules over to ArcPro's Attribute Rules and have had decent luck recreating most of the tasks. At one point I began using the ability to Copy/Paste rules because I had a lot of similar intersecting feature rules and only needed to make minor tweaks to each in order to get them set up properly. All looked good...green squares next to all rules and was able to save. No worries! However, as I began testing to confirm that the rules were working properly I suddenly found myself unable to complete any edits. Didn't matter if I double-clicked after creating a new feature, or hit F2, or pressed Finish on the edit toolbar...no love. Features were stuck in "sketch" mode. So I de-activated all rules and started going back through them one by one. When all were de-activated, I could complete an edit again. Then I went back through each rule, turning it on and checking that I still had ability to complete an edit. Eventually I came across an intersect rule created with the Copy/Paste method and noticed that I failed to change the field reference (the copied rule pointed to a different layer than the original one and the new target layer didn't contain the referenced field name). So I updated the field name and all was right again. Chalk that one up to user error. Problem is that it took a while to sort out what the issue was. My experience with creating Attribute Rules is that they won't save if there's any kind of problem with the rule logic, but Copy/Paste seems to circumvent that. To be honest, I actually like the old Attribute Assistant behavior where broken/bad rules simply don't fire off but if we're going to go with preventing non-working rules in ArcPro as the standard behavior, it would be nice to make sure that Copy/Pasted rules don't slip past rule validation checks.
... View more
We encountered slow edits (unacceptable speeds for production environment) after upgrade of Desktop to 10.6 from 10.5.1. Target data format didn't appear to matter - was painfully slow with older fGDB's, new 10.6 fGDB, SDE data in SQL 2014, all were affected. Reinstalled 10.5.1 and editing speeds back to normal. Tried 10.6.1 and edit speeds were also normal again. Didn't run down all other potential causes mentioned in this thread since 10.6 appeared to be the culprit for us. I normally don't install any first gen releases but did this time, so in the future I will I stick to my better instincts and wait for the .1 version.
... View more