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.
PLEASE! This only makes sense to me. You are already editing the stinkin table! If anytime this should be available, it should be during an edit session! So much time is wasted stopping and starting editing to accomplish this!
I can see where this might be useful if you are the only one editing the table, but you could be introducing many issues by doing this, especially in a multi-user environment. Not all people have access to adding information to the data owner accounts, and even if they did, adding columns is disabled while other users are actively connected to the feature.
For a PGDB, or a shapefile, I would be all in......... but in SDE, I would be completely against this.......
Yes, it could be considered. But any ways it will introduce a small limitation of having the field saved before entering the info in the field created since not saving the edits will altogether remove the field with the data entered in the session. Still if this functionality is added, it will be nice for atleast other tables if not for ArcSDE tables.
Adding a field is not the same as editing a table. Fields in tables don't behave like pages in Word documents or columns in an Excel spreadsheet; Tables represent schemas and have many things attached to them, like symbols, permissions, domains and ranges, etc.
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.
I agree that this would be nice but a much bigger improvement would be the ability to re-name fields after they have been created and re-order fields within a table.
I do not think this is up to Esri at all. It is handled by the underlying database engine, virtually all of which require Exclusive Locks for modifying the schema of a database. Even a database as freewheeling as Access enforces this kind of lock for this kind of change and will not allow it to occur if the table is open for editing. Such locks are not arbitrarily created by the database designers to annoy people, they exist to ensure data integrity and prevent data loss.
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.
At this time we do not have plans to modify this behavior in a future release. @rfairhur21 and @Underscore have articulated well the reasons for the current design.
I can see where this might be useful if you are the only one editing the table, but you could be introducing many issues by doing this, especially in a multi-user environment. Not all people have access to adding information to the data owner accounts, and even if they did, adding columns is disabled while other users are actively connected to the feature.
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