After creating a feature class, it would be convenient to go back after data input, and make changes to the field ordering (position).
I also support this Idea - but as a working solution I use the FieldMappings() function in ArcPy to rearrange my fields in a copied feature class.
Here's the link to the script. Feel free to send me a message if you're having trouble getting the script to run.
Just change the following values to fit your setup - then you can adjust the field names and values accordingly.
1) arcpy.env.workspace
2) input_fpath
3) output_fname
If I have to re-order fields, I use X-Ray for ArcCatalog.
Chris Rumig | GIS Analyst – Information Technology Services | Region of Waterloo
150 Frederick St, 5th Floor | Kitchener, ON N2G 4J3 | • 519.575.4830 | • mailto:crumig@regionofwaterloo.ca |7 519.575.4562 | www.regionofwaterloo.ca
Confidentiality Notice: This email correspondence (including any attachments) may contain information which is confidential and/or exempt from disclosure under applicable law, and is intended only for the use of the designated recipient(s) listed above. Any unauthorized use or disclosure is strictly prohibited. If you are not the intended recipient, or have otherwise received this message by mistake, please notify the sender by replying via email, and destroy all copies of this original correspondence (including any attachments). Thank you for your cooperation.
This is one of several main reasons why I only use Personal Geodatabase for ArcGIS. I open the database in MS Access and re-order the fields there.
I use the Table Restructure Tool in the XTools Pro extension to accomplish table reordering and other schema updates. Not to excuse Esri from including this functionality in the base ArcGIS product but they do create an opportunity for third party developers to make a living.
Didn't we have the ability to reorder fields in ArcCatalog back in the 9.# days
Oh, Robert, are you in for a shock. ESRI has deprecated support for the Personal Geodatabase. ArcGIS Pro CANNOT even read a PGD. It can read shapefiles, which are older, but not the PGD. ESRI is forcing you to migrate if you want to move forward with their future platform.
I like MS Access for a number of reasons and this is a problem with me because I'm heavily invested in PGD's, although I do have the Enterprise GDB. I'm working with the Enterprise GDB more and more, now.
I don't think so. You could always reorder the appearance of fields in ArcMap, just like now, but that doesn't change the order of the fields in the underlying data table.
This can be done with shapefiles using the ogr2ogr tool from GDAL/OGR. If combined with the Alter Field GP tool in a custom script this could produce the desired result within a file or enteprise geodatabase. It's a bit tricky to implement and would probably be susceptible to attrition. All the more reason to upvote this idea!
I suppose one hesitation may be that some organizations' programs may interact with fields via an index value, not a column name.
When making layers for services you want to use in Web AppBuilder widgets make sure your fields have the names and order you want them. You don't want to have to do it in WAB, trust me!!!!!
David zero shock at all. We have been discussing ESRI Railroading us towards their vision since the day we read about FileGeodatabases.
ESRI really needs to get a solid look at reality in many areas of their business. I work in Electric Utilities for Distribution Cooperatives. In the real world a small coop of 3500 meters cannot afford ArcGIS Server Etc...And ESRI will not let our company serve up GIS Services for our member cooperatives. We have our company GIS on SDE and we do have Server for ourselves.
We have talked to our regional manager at a number of events and ESRI really is kind of bullish.
I am not worried about ESRI support. Some of their people are brilliant others I feel I have to educate them. As long as we can continue to use Personal Geodatabases for small projects we will.
You can do it if you use SQL Server. There a setting in SSMS Tools, Options, Designers called "Prevent saving changes that require table re-creation". It's checked on by default. If you check it off, you can safely drag and reposition fields in the table designer. I can vouch for unversioned enterprise gdb feature classes and tables in SQL Server.
We use versioned data in Oracle. Sometimes the data participates in a topology or a geometric network. Since arcsde writes the sql that is sent to the database, why can't esri change the order of the fields in the sql query?
I agree! I work for a consulting engineering firm and we work for Electric Cooperatives.
I suppose we should specify the type of geodatabase you want to reorder. As has been stated, Enterprise Geodatabases do allow this. And as far as the rant on Personal GDBs... ... I really can't believe people continue to use them. Microsoft themselves have even depreciated them. Discontinued features and modified functionality in Access 2013 So I'm assuming we want this functionality on a File geodatabase, which I agree.
This is good information to have, but I just wanted to add some info about the precautions of doing this type of modification:
Change Column Order in a Table
https://msdn.microsoft.com/en-us/library/aa337556.aspx
Using SQL Server Management Studio – Right click on table > Design
*Must have Designers option unchecked
Using Transact-SQL - This task cannot be performed using Transact-SQL statements.
Caution
“Changing the column order of a table may affect code and applications that depend on the specific order of columns. These include queries, views, stored procedures, user-defined functions, and client applications. Carefully consider any changes you want to make to column order before making it. Best practice is to specify the order in which the columns are returned at the application and query level. You should not rely on the use of SELECT * to return all columns in an expected order based on the order in which they are defined in the table. Always specify the columns by name in your queries and applications in the order in which you would like them to appear.”
Ted, you are dead on and I can confirm we have done this on tables that are versioned and un-versioned, using archiving and in use by a front end applications, apps built with web-app builder as well as through the Collector app. That all sort of plays to the link Melissa provided on a best practice of making ordering changes on the front-end.
It's useful in a pinch but no substitute for good database design.
True, for us its usually multiple changes made by the business after having signed off on original requirements docs that outlined the design
I'd also like to point out that SQL Server is not providing any special functionality to allow for re-ordering columns.
SSMS Table Designer is bundling a series of steps, making it look like you are just rearranging columns:
1 - creates a new table (tmp_mytable) with column order changes that you made on mytable
2 - grants equivalent user permission to tmp_mytable (e.g. if Bill had select on mytable, it gets granted on tmp_mytable)
3 - inserts into tmp_mytable from mytable
4 - drops mytable
5 - renames tmp_mytable to mytable
This operation requires sufficient space in the data file & transaction log to handle two side-by-side copies of your table. Probably not an issue for a few thousand records, but not something I'd be too keen on doing with millions of records.
So if I did that, any advanced configurations in a feature dataset built on an ObjectID relationship, like Feature Linked Annotation, Topology validations, etc. would most likely be destroyed, since I doubt they would reload the data in such a way that the ObjectIDs are not regenerated.
A straight copy like that at the SQL Server level should preserve all the values from the original table. All ObjectIDs in registered geodatabase objects in SQL Server are maintained through separate tables & stored procedures. Tables that are not registered with the geodatabase may have sequences or other auto-incrementing columns that would have to be handled a bit differently.
But you have touched on an important thing here - manipulating geodatabase objects at the database level could be problematic, depending on what sort of behavior they participate in. This is the same reason why this isn't a simple operation at the dbms level - there are too many potential dependencies that could break or be corrupted.
My two cents worth....
When you create a new feature class/table using ArcMap, at the screen where you can add all the field names and types etc, it is possible to 'Import' the schema from an existing feature class/table, after which you can add extra fields, alter field types, names etc. But, strangely enough, you can't reorder them.
I understand how difficult it can be to re-order fields in an existing feature class (because of various underlying database issues), but at this point in time nothing has been created and we are still defining the schema. It is here that I find it strange that there is no way to reorder the fields - a simple up/down arrow would work here.
For 75% of the changes I make, it would be good enough to rename the old feature class, create a new one - importing the old schema in the process, inserting a field and reordering it before actually creating the new one, then copying the features across etc etc. Yes I can do that with scripting, but that's not really a reason why it couldn't be implemented within Arcmap, is it?
I strongly agree with Paul, I often find my self using arcpy.FCtoFC class and manually reordering the fields in the field map parameter to get the order I want. It would be nice if the I could just reorder the fields using the GUI.
Moreover, if this is considered a good idea, then it should be implemented in ArcGIS Pro, as it would be a shame if it is adopted only in ArcMap.
Angelo C - Esri Australia
That would be nice. It looks like others feel the same way. It's on ideas.esri.com:
https://community.esri.com/ideas/1362
Have you tried working with your table in ArcGIS Pro? I am only beginning to play with it, but I have heard it is meant for geoprocessing large data sets, and there is an option in the attribute table window to use field view, and it lets you rename fields, reorder them, etc. I am not sure what is going on in the background or programming, but for us front-end users- wow! I am impressed so far.
This idea is now listed as Under Consideration. I don't know how long it has been listed as such. However, I was told by a ESRI rep at a conference that if they move it to Under Consideration then that means they are going to do it if they can.
Dawg don't get your hopes up - it's been under consideration since summer 2011 lol.
SIX YEARS AGO this idea was submitted and it's got over 28,000 points. Do we need to start a Change.org petition or what?!
I was at the International conference in the early 2000's. Jack D was doing the plenary session and was talking about the next release of ArcGIS coming out was going to focus mainly on improving existing features and tools based on user input. I think it was the version in which Maplex was introduced.
I really think they need to do that again. There are hundreds of little user suggested improvements to existing tools and functions that they could focus on to make the use of ArcGIS a better experience.
I was at the UC last week. At the closing session, Jack said, “I think by next summer most of you will be running on Pro.” Pro lets you do this. Even though they’re very clear they’ll be supporting Desktop for a while, I seriously doubt they are going to put the effort into retrofitting it for this feature. I’m guessing it would be a major code change.
Are you sure Pro can do this? I disagree. Can you link to some documentation?
I'm not that impressed with Pro. I won't be using it by next summer unless something happens to Desktop.
I can't find it documented, but I just tried it in 1.2, and it works.
This topic seems to have a lot of traction lately. It might have been mentioned before that using XRay for ArcCatalog will let you do this. However, use caution because anything with a relationship class will delete the relationship--this includes attachments. The reason; it will create a copy of your table with the reordered fields and then delete the old and rename the new to what the old was. It works great just be mindful of relates.
One other thing to be mindful of, is this method will change all your edit tracking information to the time you do the reorder for all data. So if tracking is not important to you then this method works.
Just my 2 cents,
Chase
Good point, Chase. That could easily be overlooked.
I think I have an answer....
I have been able to permanently reorder and change alias names in ArcGIS by selecting the layer on an open map, selecting properties, then fields. There is a nifty screen that allows you to move fields up or down, and change the alias. Of course, saving the map makes the changes stick.
Please check this out...I am a newbie, having worked in ArcGIS for just over a year. That means I make a zillion more mistakes than most of you! And I have to figure out how to fix them. I have found this to be very helpful when new data needs to be incorporated into an existing map layer.
Cheers! And thanks for all the comments across the wide spectrum of GIS....I get a good education from all of you...
I work through a virtual machine on the ArcGIS Desktop, and have no access to Pro. I think I'm happy where I am!
I know that rearranging a layer in Desktop or ArcGIS Pro does nothing to change the field order in the underlying database, but it does work in Desktop in a saved map, And in Desktop there is a layer property screen that lets me rearrange the fields as well as being able to rearrange the fields in the table view. So even though I realize that this functionality has nothing to do with the underlying database and does nothing to satisfy this idea, it is nonetheless useful to be able to control field order at the layer and map level in Desktop.
Anyway, I tried to reorder fields in ArcGIS Pro 1.2 similar to what I can currently do in Desktop. ArcGIS Pro does allow me to reorder the fields in a table view and the fields remain in that order as long as the table view is open. However, if I close the table view and reopen it all of my field reordering disappears. As far as I can see, the ArcGIS Pro properties for the layers do not appear to have any field order screen like the one in Desktop, so there does not appear to be a way to save the field arrangement at the layer level and by extension at the Project level in ArcGIS Pro.
Although this probably needs to be under a separate idea, in my view ArcGIS Pro offers no support for any stable field reordering capabilities that would make it useful as even an equivalent of Desktop's current functionality. ArcGIS Pro needs to at least offer a way to save the field rearrangements it lets you do within a Project at the layer level so that it is stable when the table view closes and across different ArcGIS Pro sessions, like Desktop supports.
Just curious here - why do folks need this given that fields can be reordered in layer files and MXDs?
I'm not trying to be dismissive or contrary but I do think it's important to show the need for something like this, given that a) it has the potential to affect index values in a way that could negatively impact existing functionality and b) there are already work-arounds described earlier in this thread.
I need it because the field order in the underlying database table is how the fields are ordered by default when I use publish them to a feature service. When I try to use that service in ArcGIS Online and I want to re-arrange the fields to make it easier for editors to fin similar information, the process for reordering those fields for editing is very tedious. I believe it also impacts the field order when editing in Desktop.
<http://www.dickssportinggoods.com/home/index.jsp>
Todd Henry
Sr Technical Manager, Real Estate Market Research
345 Court Street l Coraopolis, PA 15108
todd.henry@dcsg.com<mailto:todd.henry@dcsg.com> l o: 724.273.4026 l m: 412.522.3269
<http://www.facebook.com/dickssportinggoods>[cid:image003.jpg@01CEB48E.2B0533C0]<https://twitter.com/DICKS>
I second Todd's point. The reason field rearrangement is needed at the database level is that it directly affects how fields are displayed in a published ArcGIS Online service. It's possible to waste up to 45 minutes tediously rearranging field orders in ArcGIS Online given more than 20 fields in an attribute table. Securing an order is possible only at the database level, as ArcGIS Online has the conspicuous tendency to rearrange aliases after publishing, seemingly at random.
Re-ordering the fields using the Table View (right-click on the layer, click Design, and Fields) will allow you to save the order in your project. You must save the changes that you make in the Field View for them to stick. This isn't physically re-ordering them in the underlying dbms table, but changing the order in which they are queried when you open the attributes of the layer in your map. This is a little different than ArcMap, but the equivalent functionality is there.
Todd Henry and Jason Matney, I was under the impression that ArcGIS Server/AGOL publishing would honor whatever settings were made in the published MXD, although I've never tried to publish with re-ordered fields so I don't have experience in that area. If it does not then that is indeed a good justification for the idea.
If ArcGIS Server/AGOL does not honor the field re-ordering set in the published MXD, than that should be fixed as well. Anyone know of an "idea" out there for that? I would happily upvote.
I had submitted the issue with Feature Service field order as a Bug if anyone wants to add their name to this to raiser the severity.
#BUG-000090535 [Enhancement] Feature Service Fields List Order is not maintained on REST
As far as the Feature Class field order, sometimes we may add a field that is related to other fields and it would be nice if it were in logical order in the GDB schema rather than having to move it around in the MXD. For instance, if we add a "Unit_Number" field it would be nice to put it after the other address fields in the database.
Mele
Todd -
Thanks for sharing this perspective of why you need to reorder the fields in your organization. Your reason for needing to reorder the fields permanently is due to the layer ordering not persisting through to your published feature services.
This has been documented as a known issue and is being reviewed. Please contact support services if you would like to be linked to this defect. This is specific to feature services and does not occur with map services.
BUG-000090535 - Feature Service Fields List Order is not maintained on REST endpoint.
Over 6-year old, top voted (twice as many as the second most) idea and still ArcGIS doesn't have this ability. I don't know why I even bother anymore to look up if this functionality has been added. Oh yeah, it's because I keep needing to do this but end up having to basically build a completely new schema into which to import the same data. At least support this on the non-SDE feature classes. Who or what is standing in the way of this? Stop the sandbagging already.
Quite possibly it gets ignored because it may not be possible to do it in a FileGeodatabase due to the nature of this type of database. And ESRI seems to have a push to make people use FileGeodatabases instead of Personal. We can easily reorder fields in PersonalGeodatabases but that does not help File users.
While a pure reordering of fields in an existing layer may not be possible, it can be done if you look at it another way. Let the user select the order they wish the fields to be laid out. Create a new empty copy of the layer with that structure and then transfer the existing data to this new layer. Create any permissions, indexes, etc on this new layer as it exists on the original layer. Delete the original layer and rename the new one. This is basically what SQL Server does in the background when a user reorders fields on a table. As far as the user is concerned, they are just reordering fields. They do not need to know the detail of how much work is actually being performed in the background, it just happens.
There's a great Add-In, X-Ray for ArcCatalog I just found that does just this. Along with some other great geodatabase management tools, it allows you to re-order fields for file gdb's or SDE. More importantly it honors table functionality such as attachments and cartographic representations, which can get dropped with other tools. Worth a look. Available in 10.1 or 10.2 and above.
X-Ray for ArcCatalog download link.
X-Ray lets your reorder fields for schema, but not for an existing geodatabase that already contains data.
GeoNet <https://community.esri.com/?et=watches.email.idea_comment>
ArcGIS should allow the ability to permanently reorder fields in a table
new comment by Michael Barker<https://community.esri.com/people/mbarker> View all comments on this idea<https://community.esri.com/ideas/1362?commentID=40798#comment-40798>
Todd,
As Melissa said, this is a bug with Portal 10.3 and 10.4 and probably AGOL. After talking with our agency specialist and Esri support, I found that the best workaround is to use ArcGIS Pro for publishing. Of course, Pro won't work with ArcGIS Server (hopefully that's coming.)
See Enable ArcGIS Pro to access ESRI Personal Geodatabases and https://community.esri.com/ideas/16654
Sign in to post, follow content, and more. New here? Register for free.
