Indicator in Operations Dashboard Showing Incorrect Count

7380
21
03-21-2018 12:24 PM
ISP_graynic
Occasional Contributor II

I am trying to create an indicator in the new Operations Dashboard and want to have it display the count of my features.  When I do so however, it gives an incorrect number.  The layer should have 42 features (and it even shows that if you open the table when creating the indicator), however when I actually create the indicator it shows 143 features.  Does anyone have any ideas why it's giving me a wrong count when it should say 42 instead of 143?

Thanks!

21 Replies
AbdulJabbar1
New Contributor III

Hi Michael,

Yes, the layer ''actually layers'' are being edited in the field using Collector on regular basis. 

0 Kudos
ISP_graynic
Occasional Contributor II

After some time with ESRI, we think we found the issue.  For my layer, there were attachments as well as a related table.  When I removed the attachments and the related table in the SDE, the Indicator showed the correct number.  For some reason the Count in the Indicator must have been counting either the attachments or some of the related records.


Hope this helps!

WilliamPelchat
Occasional Contributor

This is still happening last I tested it on 9/21/2018! Looks like any feature class with attachments is counted wrong, may also be including related features. Indicator widget is unusable for us in the dashboards for most of our applications because of this since we use related classes and most have attachments. This in using AGO and we host our own services on a public AGS.

As mentioned previously, the table count is correct on show preview

Brettmartin4
New Contributor

We are at 10.6.1 and this is still an issue. I have attachments that I require for this workflow. This should be a very basic query. Filter widget in WAB has no problem with this same data. Can anyone provide a solution that does not involve removing attachments?

0 Kudos
SSMIC3038
Occasional Contributor III

Hi, were having exactly the exact same problem, did you find any solution to this?

0 Kudos
AndreaBefus
New Contributor

I am having the same issue. I have a layer with attachments and a related table and the indicator is still showing the wrong number. Anyone have a solution where we don't have to disable attachments?

0 Kudos
NathanielSimmons
New Contributor III

I am having the same issue as well. Has there been a solution found yet? This really needs resolved ESRI...

0 Kudos
NathanielSimmons
New Contributor III

Andrea, 

I'm not sure if you are still having this issue, but I found a work-around. I was trying to display a count for a feature (with attachments) published through a PostgresSQL database, which seems to have been the problem. After publishing the feature to an SQL Server database, the indicator displayed the correct number of features, even with the attachments enabled!!

Depending on the situation, creating a new database just to get the indicator to display the correct feature count hardly seems like a reasonable work-around. But, I wanted to let anyone who is having the same issue know about possible fix... This still needs looked at by ESRI though.

0 Kudos
AndreaBefus
New Contributor

Thank you for sharing your workaround. Unfortunately this layer has to be housed on an Oracle database where all of the other data is located.

0 Kudos
NathanielSimmons
New Contributor III

So, after more tests, it seems that the issue arises if the feature class is not organically created in the sde database. If you create the layer based on an imported shapefile, the indicator count issue seems to be incorrect.

However, the issue was resolved after copying the data from the current sde database to another sde database, and then importing it back into the original sde database (as a new layer). 

Contrary to my previous post, it seems like the database platform was not really the issue. Copying the feature class out and bringing it back in seemed to reset the schema and it also avoided the strange bugs that occurred previously. You should give that a try and see if it works since it did for us.  

0 Kudos