Is this expected behavior on 2.6.1? This is VERY DANGEROUS. * Select a record in attribute table. Right click on field, calculate field, specify a string to calculate, hit APPLY * make sure and leave the field calculator floating window open * change the selection in the table to a different record * the field calculator window is already open, don't change anything except a new string to calculate, hit APPLY or OK, doesn't matter Notice what happens…you would expect that the record selected in step #3 would be calculated, i.e. the one currently selected, but it actually calculates the formally selected record, i.e. the selection in step #1.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

2.6.1 - field calculator with selection, dangerous bug

danbecker

Is this expected behavior on 2.6.1? This is VERY DANGEROUS.

Select a record in attribute table. Right click on field, calculate field, specify a string to calculate, hit APPLY
make sure and leave the field calculator floating window open
change the selection in the table to a different record
the field calculator window is already open, don't change anything except a new string to calculate, hit APPLY or OK, doesn't matter

Notice what happens…you would expect that the record selected in step #3 would be calculated, i.e. the one currently selected, but it actually calculates the formally selected record, i.e. the selection in step #1.

Najděte více příspěvků označených jako

Accepted answers

Robert LeClair

Working with Dan directly, I was able to repro this issue. Short story is a hosted feature layer published from Survey 123 Connect and then added to a Map View in ArcGIS Pro will cause this calculation error seen by Dan. I've reported it to Esri Support Services as a BUG. More to come.

danbecker

Win 10 Pro is fully updated, version 2004

Win. control panel, uninstalled Pro, then rebooted.

Clean install 2.6, opened the same Pro project as before, then the same local C:\ FGDB, the problem still persists.

Installed 2.6.1 patch atop 2.6.

Created a new blank project, accessed the same local C:\ FGDB, problem solved

Closed new blank project.

Opened same Pro project as before, then the same local C:\ FGDB, the problem still persists.

Removed all items in geoprocessing history (147 of them), the problem still persists.

Edit: testing continues..

Created new Pro project using an existing template we had.

Had 2 instances of Pro open, the problematic project from above and the new one. I then copy/pasted the Pro map over to the new Project.

In the new project, I now have the original map from the old project. I Field calculated the same local C:\ FGDB, the problem still persists.

Created a new blank map in the new Pro project, I Field calculated the same local C:\ FGDB, problem solved

So, this bug is related to the Pro map, project, which makes sense, because my Collegue and I are working on the "same" project/map. He opened the original and did a SAVE-AS, I'm still using the original.

Edit: finally figured out the bug, it's related to a Hosted Feature Layer being present in the map.

Steps to test attribute calculation:

Select a record in attribute table. Right click on field, calculate field, specify a string to calculate, hit APPLY
make sure and leave the field calculator floating window open
change the selection in the table to a different record
the field calculator window is already open, don't change anything except a new string to calculate, hit APPLY or OK, doesn't matter

Steps to Repo the issue with calculating attributes when HFL is present in the map:

Create a new blank pro project. Insert a new blank map. Add a single FGDB layer to the map.
Perform the above "Steps to test attribute calculation". Everything will work as expected.
Add a HFL to your map. We use Enterprise, I have not tested AGOL HFLs.
Perform the above "Steps to test attribute calculation". You will see the problem where the incorrect record is calculated.
Remove the HFL. Perform the above "Steps to test attribute calculation". You will see the problem where the incorrect record is calculated.
Once the HFL is added, even after it's removed, the attribute calculation problem persists. It's not corrected until you create a new map.

All comments

WWalker

I'm experiencing this issue at 3.3. No hosted feature layers. Only local FGDBs and imagery.

danbecker

Win 10 Pro is fully updated, version 2004

Win. control panel, uninstalled Pro, then rebooted.

Clean install 2.6, opened the same Pro project as before, then the same local C:\ FGDB, the problem still persists.

Installed 2.6.1 patch atop 2.6.

Created a new blank project, accessed the same local C:\ FGDB, problem solved

Closed new blank project.

Opened same Pro project as before, then the same local C:\ FGDB, the problem still persists.

Removed all items in geoprocessing history (147 of them), the problem still persists.

Edit: testing continues..

Created new Pro project using an existing template we had.

Had 2 instances of Pro open, the problematic project from above and the new one. I then copy/pasted the Pro map over to the new Project.

In the new project, I now have the original map from the old project. I Field calculated the same local C:\ FGDB, the problem still persists.

Created a new blank map in the new Pro project, I Field calculated the same local C:\ FGDB, problem solved

Edit: finally figured out the bug, it's related to a Hosted Feature Layer being present in the map.

Steps to test attribute calculation:

Select a record in attribute table. Right click on field, calculate field, specify a string to calculate, hit APPLY
make sure and leave the field calculator floating window open
change the selection in the table to a different record
the field calculator window is already open, don't change anything except a new string to calculate, hit APPLY or OK, doesn't matter

Steps to Repo the issue with calculating attributes when HFL is present in the map:

Create a new blank pro project. Insert a new blank map. Add a single FGDB layer to the map.
Perform the above "Steps to test attribute calculation". Everything will work as expected.
Add a HFL to your map. We use Enterprise, I have not tested AGOL HFLs.
Perform the above "Steps to test attribute calculation". You will see the problem where the incorrect record is calculated.
Remove the HFL. Perform the above "Steps to test attribute calculation". You will see the problem where the incorrect record is calculated.
Once the HFL is added, even after it's removed, the attribute calculation problem persists. It's not corrected until you create a new map.

Robert LeClair

Followed the same "create a new FGDB on local c, created..." and can't replicate either. Strange...

danbecker

I created a new FGDB on local C, created new poly feat class with 1 field. Digitized 2 non-overlapping polys.

Same result, the incorrect record is calculated, just like the initial steps.

So, this has nothing to do with the location of the FGDB (local vs. network share)

danretired

I can't replicate. Clean install of 2.6, 2.6.1 updated on top of it. Local fgdb table.

Robert LeClair

Can you share the FC as an *.xml Workspace document so I can test on my side? If so my email address is rleclair AT esri dot com

Thx!

danbecker

I renamed both those folders to _old, then re-opened Pro, and navigated to the same FGDB for the test calc's, the issue still persists.

Robert LeClair

Ok - thx for the update. Try this - rename the Esri folder in your C:\Users\<user profile>\appdata\local and C:\Users\<user profile>\appdata\roaming to Esri_Old and repeat your workflow. Does the issue persist?

danbecker

I have never done a clean install, I've upgraded several versions atop each other. I installed 2.6, then 2.6.1 (the SP), the update was not a clean install. A co-worker was able to repo. the issue, he also did not clean install, actually, can't because I'm the person with admin. privs to run installs.

Robert LeClair

Thx for the update. When you installed AGP 2.6.x was it a clean install from AGP 2.5? What I mean - did you completely uninstall AGP 2.5 prior to cleanly installing AGP 2.6.x? Or did you upgrade AGP 2.5 to 2.6? The reason I ask I did a clean uninstall of 2.5 before installing 2.6 and do not see this workflow.

danbecker

When I documented the steps above, I was using an SDE GDB (postgreSQL 9.5), unversioned, archiving enabled.

So, I created a new FGDB on disk, found a random poly feature class from a different FGDB, copy/pasted it into the new FGDB, then completed the above steps.

Same result. The first selected record is calculated.

Robert LeClair

Dan - I followed your steps precisely and do not see what you're describing. One test to consider - copy/paste the existing feature class in your geodatabase as a new feature class in the same geodatabase. Repeat the workflow. Do you see the same result? If so, try this - create a new file geodatabase and copy/paste the feature class to the new geodatabase. Repeat the same workflow. Do you see the same result? Please advise.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.