ArcPro not honoring selection for attribute statistics

3827
16
11-04-2022 10:11 AM
ChristopherJStrong
Occasional Contributor

All I'm trying to do is get a total value for the Shape.STLength() field for a feature class. I've selected the records I care about, but when I right click on the field and choose statistics, I get the statistics for all records. The attribute table is only showing selected records, and the only filter option is by extent.

What am I missing here?  This should be very simple (and it is in ArcMap, which I am seriously wishing I could just use forever).

Screenshot attached. 

selectionissue.JPG

16 Replies
Robert_LeClair
Esri Notable Contributor

Christopher - what ArcGIS Pro release are you using?  I'm using ArcGIS Pro 3.x and have the Selection Filter on my distribution statistics as seen below.  It does honor selections and shows the dataset statistics as well.
Statistics.JPG

ChristopherJStrong
Occasional Contributor

Thanks for the reply, Robert.

I'm using ArcPro 3.0.2 as well.  I just tried again on a different dataset, and same issue as before.  My process is to 1) open the attribute table 2) select by attributes 3) right click on the field and pick Statistics.  I have tried other fields as well, with the same results.

Robert_LeClair
Esri Notable Contributor

That's very odd.  It seems your ArcGIS Pro 3.0.2 is missing the Selection Filter for the chart.  I know this sounds strange but give it a go - close ArcGIS Pro, rename the Esri  folder in your C:\users\<user_profile>\appdata\local and C:\users\<user_profile>\appdata\roaming to ESRI_OLD.  Then restart ArcGIS Pro, load your data in a new Pro project and try the workflow again.  Does the Selection Filter show?

alex_friant
Frequent Contributor

@Robert_LeClair - Did you try creating the chart using a connection to an EGDB feature class layer? It appears the problem only happens with SDE connections.

ChristopherJStrong
Occasional Contributor

@Robert_LeClair  I have tried renaming the ESRI directory to ESRI_OLD in both AppData directories with no change to the issue.

alex_friant
Frequent Contributor

I'm seeing this same issue but only with enterprise geodatabases/sde connections. If I export the EGDB feature class to a File Geodatabase, the issue goes away. I'm using ArcGIS Pro 3.0.3.

Feeling like this is a bug, because the "Selection" filter appears when the Chart is first being created and is loading the data, but as soon as the data is loaded, the button disappears. Makes no sense for the Selection filter to disappear just because the layer is in an EGDB by design.

ChristopherJStrong
Occasional Contributor

Thanks @alex_friant.  I can confirm that exporting to a file geodatabase produces the correct charts/statistics.  Connecting directly to an EGDB or using an SDE connection both produce the same issue.

Robert_LeClair
Esri Notable Contributor

I can confirm this is BUG-000153835 - Incorrect statistics are displayed for a selection of features if the selection is made prior to creating the field statistics chart and the data resides in an eGDB.  I created a PosgreSQL eGDB and saw the same behavior as you as well as the term "selection" briefly appearing before it disappears.

Current workaround is:

  1. Open the chart properties first and make the selection in the map second.  You'll see the expected statistics in Chart Properties but the chart will not update.
  2. Copy the data into a file geodatabase and conduct the workflow there.

The BUG is currently under review by Esri Support Services and the Geodata team.

AZendel
Frequent Contributor

I'm seeing this on an Oracle EGDB as well. I'm still using Pro 3.0.3, but 3.1.0 is available. But based on the bug report, I don't think this this has been fixed. @Robert_LeClair, it may not hurt to let the staff that are addressing the bug know that I've run into the issue on an Oracle SDE instance as well. It's happening on the SHAPE.Area field and a separate double precision field that has nothing to do with the geometry. 

I'm glad that the statistics that it was reporting were so out of the park that something was blatantly wrong. Otherwise, I could have reported some bad numbers and that should never be considered acceptable. I think this bug warrants faster action than it appears to have received so far.