Select to view content in your preferred language

ArcGIS Pro 3.2 Export Table field edits revert before exporting

970
8
12-05-2023 05:58 AM
AndrewJarvis
Occasional Contributor

We just migrated to 3.2 recently, and this is the first time I've needed to use a .csv file.  In the past, I would add the .csv file to the project, use the Export Table function to change data types, alias, etc., and then save to my geodatabase, and then I could join the table to an existing layer and everything was fine.

However, in 3.2 when I make those changes, they always revert to the original settings before exporting:

2023-12-05_08-48-30.jpg

All I'm doing is removing fields and changing ZIP from numeric to text so that I can use it to join as usual:

2023-12-05_08-49-16.jpg

When I hit OK, it reverts back to the first picture.  I've even tried creating new fields with the field type I need, but that doesn't work either; all changes are blown out after hitting OK.  This is really hindering my work and I don't want to have to clean my data before using it since I never had to before.  Any help would be greatly appreciated.

 

0 Kudos
8 Replies
DonNadeau-GISOffice
Occasional Contributor

Complete guess:  try renaming the cvs to have no blanks (use a simple name).

 

0 Kudos
DonNadeau-GISOffice
Occasional Contributor

Also, your first pic shows an alert (exclamation point on a yellow-gold warning triangle) by your new file name (and path).  Click on that for the message, and it may point to another solution.  Click on the folder icon to the right of it, and make sure you have a valid path.  I hope these ideas help!

0 Kudos
DonNadeau-GISOffice
Occasional Contributor

Also: if your numeric zipcode is "zip+4" a.k.a. nine digits, then you need to re-code your translation to match, with nine rather than the five characters input in your pic.  Or not.  Good luck!

0 Kudos
AndrewJarvis
Occasional Contributor

The ZIPs in my file are only 5 digit; this method has worked for years, but you're right, if they were ZIP+4, I believe it would actually be a length of 10 to accommodate the hyphen as well.  Good suggestion though.

0 Kudos
AndrewJarvis
Occasional Contributor

That was only a warning to let me know that I had already exported under that name; it overwrites anyway.  However, when I tried the new name without spaces, that wasn't the case, but still got the same behavior of reverting to the original settings.

0 Kudos
AndrewJarvis
Occasional Contributor

First of all, thank you for the suggestions!  I'll respond to each in case anyone else is thinking of trying these.  I've never needed the file name itself to not have spaces (only database names and objects) but I tried just to see, but I got the same behavior.

0 Kudos
StephenFrancisco
New Contributor

This is also happening to me, with exporting a gdb table to csv. Did you ever find a solution @AndrewJarvis ?

0 Kudos
AndrewJarvis
Occasional Contributor

Hi @StephenFrancisco, sadly, I haven't found a solution yet.  Currently, I have 2 workstations, one with 3.1, and one with 3.2.  Depending on my workflow, I'll either open 3.1 and perform the export to the geodatabase and then go to my 3.2 box and continue, or I'll have to clean/format the data before working with it in 3.2.  It's frustrating, but I can only hope it's addressed with a future release.

0 Kudos