Join and Field Calculator issues with Pro 3.2.0

[Eugene_Adkins]

Hi,

I updated from Pro 3.1.1 to 3.2.0 yesterday, but I came across some major functionality issues with a basic process and I'm wondering if anyone has faced the same.

I'm dealing with a published feature service (with an Enterprise GDB via Portal 10.9.1) that includes a feature class and a related table.

When I join the table to the feature service based on the facility ID the relationship is based upon, the Validate Join process gives no error, and the numbers of resulting input table and join table match perfectly.

After applying the join, the joined data appears in the attribute table as normal, but if I try to update field information in a table column based on field information from a feature service column the field calculator appears to run "normally" but the data does not get copied.

This issue did not occur until I updated to 3.2.0 ... has anyone noticed anything similar? As of now I'm going to have uninstall 3.2.0 and go back to 3.1.1 because 3.2.0 is making it impossible for me to complete my workflows.

Thanks!

[ZachBodenner]

I've experienced something similar that I suspect might be related though superficially it's a very different process from yours:

I was very excited for the single-workspace editing session option in Pro, so I upgraded to 3.2 and enabled it right away. So I had a feature class with related table in my egdb. I joined the two (GlobalID - GUID) and tried to run a field calculation and got basically an nothing-burger of an error message. After some fiddling, I was able to get the field calculation when joined to work, but I had to go back into Pro's editing options and uncheck "Enable and disable editing from the editing tab." 

Again, might not be related but I have encountered issues with joining and editing.

[Eugene_Adkins]

Thanks for that idea, Zach.

Just checked the options and "Enable and disable editing from the Edit tab" is currently unchecked on my end.

I talked with tech-support, but I was not able to follow-through completely with the Enterprise GDB team because I simply don't have the time to troubleshoot because I cannot complete normal workflows with this version of Pro.

[chill_gis_dude]

I manage an ArcGIS Enterprise deployment and we have noticed similar issues after upgrading to Pro 3.0 and higher and have completely gone back to 2.9.

We have models that run weekly to do select by locations and then calculate the geometry (acreage) of those selected polygons and have noticed that it is calculating erroneous acreages inconsistently. An obvious 20 or 40 acre polygon being calculated as 6 acres etc.

We have also noticed similar issues with field calculator where we are just calculating field3 to be a simple concatenation of field1 and field2 and have noticed that it pulls in data from other fields not even referenced in the expression. 

We've pretty much lost all faith in the field calculator and calculate geometry tools, two of the most important tools in Pro. Its like buying a calculator and the "+" not working correctly every time. Trying to get them logged as bugs but the issues are very hard to reproduce. 

Our layers are stored in an enterprise geodatabase driven by SQL Server 2016. 

[jfischer91]

I've encountered similar issues when trying to calculate acreages for polygons in a service coming from Enterprise, using Pro 3.2. Very strange. For me, if I try to do a lot at once, it seems to do it incorrectly, so I need to do 2-3 features at a time, which is not viable. I made a separate post about that here:

https://community.esri.com/t5/arcgis-pro-questions/arcgis-pro-area-calculations-are-incorrect-and/m-...

[chill_gis_dude]

I worked for several months with an ESRI analyst and actually got this logged as a bug. I just got an email the other day that it was addressed in 3.5. For some reason I can't look up the bug # anymore but I have it in myesri and can share details with you.

Updates have been made to the following defect which you are associated with:
BUG-000171641 - When the Calculate Geometry geoprocessing tool is run on an enterprise geodatabase polygon feature class with attachments enabled and 65 or more records selected, the tool completes, but the values are applied to the wrong records.

Status: Fixed (Learn More)
Version Fixed: 3.5
Additional Information: This issue is addressed in 3.5

Alternate Solutio...

• Disable the attachments on the feature class, close and reopen ArcGIS Pro, then run Calculate Geometry again to see the expected values when making a selection of 65 or more features.
  • If attachments are still enabled, run Calculate Geometry on 64 features or less to see the expected values.
  • Run Calculate Geometry on the feature class as a whole instead of a selection of features if attachments are enabled.

    I did not like their suggested workarounds because they seemed finicky so I used a different workaround that the analyst suggested and it has worked without fail while we wait to upgrade to 3.5. I export any features I want to calculate geometry on to a file geodatabase preserving global ID's. I then calculate geometries in the file geodatabase and join the data back (using globalIDs) to the original layer in my enterprise geodatabase and use the field calculator to populate the values. 

I use a different workaround while we wait to upgrade to 3.5. I export the features from my enterprise geodatabase to a file geodatabase (preserving globalIDs), calculate any geometries from the file geodatabase, then join the data back using global IDs, and use the field calculator to populate the values from the file geodatabase. I've tested it thoroughly, the issue is not reproducible in a file geodatabase. 

[Eugene_Adkins]

Thanks for the update. I’m staying at version 3.1.x for a while. It’s compatible with our server version, and any supposed “advantage” of upgrading to a newer version seems to be heavily offset by bugs that affect fairly basic workflows and functionality.

[jfischer91]

Noticing similar behavior in Pro 3.2. I have 2 layers in AGOL that I pulled into Pro, did a join on a common field, and trying to populate values into a field in layer 1 with a value from a field in layer 2. The operation runs successfully but no data is populated.