Undo a field calculation in ArcPro

5568
12
10-27-2016 06:59 AM
RichardHughes2
Occasional Contributor III

How is it possible to undo a field calculation in ArcGIS Pro?  In ArcMap the edit session allow for undo, in ArcPro what is the solution?  There is a solution for this right?  Otherwise field calculations are not safe.

Tags (1)
12 Replies
DanPatterson_Retired
MVP Esteemed Contributor

Well they are always safe if you follow the practice of adding a new field, doing the calculation there rather than overwriting an existing field.  If the calculation is ok, then delete the old field.  I have never overwritten an existing field for that very reason.  You can use the values from an existing field, just as you would if you were going to overwrite it

RichardHughes2
Occasional Contributor III

That is true, it is possible to create a new field then delete the old field and rename the new field to match the old field name.  The fact that you cannot have two fields with the same name makes the solution a little bit of a hack and not a solution, especially since it works in ArcMap.

DanPatterson_Retired
MVP Esteemed Contributor

It isn't a hack since I don't create the same name for the clone.  You only get bitten once by forgetting to get into an edit mode (even if available) and overwriting a calculation gone bad. If you really must have an identical field name as the first then do the calculation in a new field (X_clone) using the values in the original (X), things are good?, delete X,.... then make a new field called X and copy X_clone to the newly created X... hence X is back from its clone.  Now you are going to say they are out of order... sure, but when you are done with all the calculations and you really need them to be in the original order then there are tools to do that which creates a new feature class.

Of course this can be all avoided by copying the mission critical layer to a new one doing the calculations there... then if they are good, do them in the original.  It all depends on how important stuff is... that will determine the lengths that one will go to maintain the integrity of ones data.  As I said, you only get bitten once, and why multiple backups of the originals, doing calculations on cloned fields or replicate layers, isn't a hack... but good practice.  Good luck

ChristopherKohler1
New Contributor III

These work-arounds are frustrating. 

Field calculations does not equal typical attribute edits for single features. I fully understand there is different processes going on between the two.

In my case, I have to edit over 6,000 hydrants into 3 types. Obviously, single feature editing would not be efficient. Field calculator is great until I accidentally calculate with "show all records" instead of "show selected records" in my table.

To do what you suggest Patterson, I would need to create and trade values from another column. However, another step of reorganizing my values, at this point I wonder if ESRI could develop, or implement a new behavior for the field calculator. To allow reverts, or at least discard and replace values with original values stored from temporary memory. 

Again I am not a computer scientist( B.S. Geology with GIS experience both professional and academic) but feel this would streamline and optimize users workflows. 

DanPatterson_Retired
MVP Esteemed Contributor

I understand the frustration. But as I indicated... you only get bitten once... It would be nice, though, to have an extra check to ensure that you really want 'all records' calculated when you really want 'selected records' calculated  Could be a suggestion for https://community.esri.com/community/arcgis-ideas?sr=search&searchId=30530441-f6dc-49f0-8702-19de7cb...‌... it might garner some support

DanPatterson_Retired
MVP Esteemed Contributor
JamesFournier1
New Contributor III

Yes, I was very happy to see this added at 2.6!  Thank you Esri team!

0 Kudos
JamesFournier1
New Contributor III

Adding a new temporary field every time you need to perform a field calculation seems like a lot of extra work.  A lot of people are going to be "bitten" by this when they use it for the first time because its only natural to expect an undo function when its always been there for you in the past.  Also, since the default calculation script has switched from VB in ArcMap to Python in Pro there is a high probability that user's calculations won't turn out as expected the first go around.  It shouldn't have to be that way.  I've added my vote on ArcGIS ideas.

RobertHursey
Occasional Contributor

Exactly. I have been "bitten" as well and the data I edit is used for 9-1-1.  We now have an undo option, but it is unchecked by default with no warning message for "edits outside of an edit session cannot be undone" - paraphrasing from ArcMap, but the point is field calculations should be as forgiving as in ArcMap.  Dan's suggestion above does not work in the case of an SDE data base with limited access to field creation.  I would have to use a fgdb first and then duplicate the work to SDE.