Attribute Table Field Name Renaming

Question

when i am working with Attribute Table,i have a problem of changing the name or properties of the already created field name that has records in it.what i always do is just adding another field and calculating all the records in the previous field and delete that field.These affects the sequence of fields added.HOW CAN I SOLVE THIS TYPE OF PROBLEM?

Any ideas or recommendations?

Seid

TimothyHales · Answer

This idea has been submitted on the ArcGIS Ideas page: Make changes to fields after they have been created.  Check it out and vote on it.

RichardFairhurst · Answer

when i am working with Attribute Table,i have a problem of changing the name or properties of the already created field name that has records in it.what i always do is just adding another field and calculating all the records in the previous field and delete that field.These affects the sequence of fields added.HOW CAN I SOLVE THIS TYPE OF PROBLEM?

Any ideas or recommendations?

Seid

If you have Microsoft Access and the original ObjectID order of your original feature class is not important to preserve (for relationship classes or other multi-table key fields) the easiest way to do this is to create a personal geodatabase.  You can export the whole feature class into the personal geodatabase, but there may be a loss of spatial precision if your source data is in SDE or a file geodatabase.  However, all you really need is the feature class field structure, which can be exported from the original feature class without records by adding a definition query to the data that filters out all records and doing an export.

In Access you can open the personal geodatabase file and rename, rearrange, and redefine the field structure of your feature class anyway you want easily (but that is the only easy part).  If you do not need to preserve spatial precision for SDE or a file geodatabase and you exported all of the original features, this restructured feature class can replace your original feature class and you do not need to do anything else.

If you need to preserve the original data's spatial precision then after all the fields are laid out in Access the way you want, create a new feature class in the original workspace and import all of the spatial characteristics of your original layer.  Import the field structure from the restructured personal geodatabase file.

Now reload the data from the original feature class.  Renamed fields will need to be matched in the load process.  If you want to downgrade a double to a long or short, you need to have a temporary double field in the structure to transfer the data from the original, since you cannot match a double to anything but a double or a string field in the load dialog (longs cannot become shorts directly either, only long, double or string).  String values that you want to convert to dates or numeric values should also be loaded into temporary string fields rather than directly into the new date or numeric fields to avoid load errors and record losses from bad conversions.  After the load completes calculate over any double values to your long/short permanent fields and any strings that are to become dates or numeric values into their new fields and delete the temporary double/string fields.

Obviously this is a pain to do even using the above method, since there are so many steps, but ESRI has no functionalty that comes close to what Access is capable of doing.  (This may not work for certain complex feature classes that cannot use the simple load dialog, such a network built using Network Analyst).

If preservation of the original ObjectID values is essential and they cannot be altered in any way, there is no simple way to do this.  If you are willing to rebuild the relationship keys to match a new set of ObjectID values, then the above methods can be used if you first create a temporary field to hold the original ObjectID values of your original data prior to any restructuring.  Then you can use that temporary ObjectID value as a join to recalculate all of the foriegn keys in your related tables/feature classes to the new ObjectID of your new feaure class.  After that you can rebuild your relationship classes.