Not in Current Product Plan
Score8910
It would be nice to be able to add a column or delete a column in an attribute table while you are in edit mode. Instead of having to stop editing add the column then continue editing again.
Add a column in an attribute table while you are in edit mode
- Comment • 10
For a PGDB, or a shapefile, I would be all in......... but in SDE, I would be completely against this.......
Still if this functionality is added, it will be nice for atleast other tables if not for ArcSDE tables.
The structure of a table represents the design of the objects it represents. The data in the tables represent the values for that design. I write and use programs that access databases. There is nowhere I can think of where I allow the user to add and remove fields. Rather, they add, edit, and delete data. If, as a programmer, I introduce or remove a field from a database, I have to make changes to my executable and redeploy it. My users will simply edit data in the new fields.
ESRI's model is following a standard, I think, which I don't think we should ask to change. The ability to do something in edit mode also allows one to undo, or to stop editing without saving changes. I see no possible way that manipulating fields in an "undo" environment would work. There's too much at stake.
In my experience, if I have to add or remove fields in edit mode, it means I've designed the layer poorly. I should've thought of this or that attribute to further represent my features, but I did not. "OK," I think, "I'll save my edits, stop editing, and add the field I should've added." Then I get back into editing.
Adding a field may seem innocent, but deleting a field or changing its type is not a recoverable event without a backup and could definitely result in loss of data actually entered during the edit session. If you have the ability to add a field you virtually always have the ability to delete a field. For the true multi-user databases used by SDE this kind of functionality is just not an option, as all editors should definitely be taken out of the system before such a change is made and that change should only be made by the database administrator, not just any old user (who should take care to notify programmers of the change, since programs built around the existing schema will likely fail as a result).
I fully support improving the interface to allow easier and more flexible schema changes to be made to an existing database structure (renaming fields, reordering fields, inserting new fields at users specified positions in the field list, deleting fields, changing field types, applying or removing unique or sorted indexes, subtype and domain changes, etc.), but only if the locking structure of the databases are respected and appropriate warnings are given about possible data loss with the option to cancel the change. The restructuring operation also must consider relationship class, annotation class, network dataset, topology, etc. dependencies and preserve ObjectIDs and GlobaIDs to not break such dependencies, or I would be against it.
My Blog
My Company