AnsweredAssumed Answered

Model output data fields are prefixed with the name or names of the originating table

Question asked by geonetadmin on Apr 30, 2010
Latest reply on May 10, 2010 by geonetadmin
Original User: Geraldtaylor

Greetings all

My organization is trying to solve a number of technical issues before we can consider migrating from a
command line/coverage environment to a geodatabase. The most difficult of these appears to be how to automate our standard soil/wetlands analysis of farm parcels in a GDB environment.

We currently use an old AML script that I wrote back in 2000 and have maintained since. Some time ago, I built a geoprocessing model that should approximate the functions of the AML outputting a personal GDB containing three feature classes. Unfortunately, the field names in the output data are prefixed with the name or names of the originating tables. e.g. �??Allsoils_polygon_OWNER�?� or �??Allsoils_MUSYM�?�. This will not work with our Access report templates. We need the original field names.

On the advice of ESRI tech support I tried setting the model environments to �??Maintain fully qualified field names�?� and using the field mapping in the Feature class to Feature Class tool to alter the output field names to the originals.

This had the desired effect �?? Once.

As soon as any of the input parameters were changed whether a different parcel, wetlands, or soils data set, the problem came back. Apparently changing anything �??upstream�?� of a process resets it to its defaults.
Our problem was ultimately added to a couple bug reports at ESRI .

NIM033788; Maintain Field Map settings when the data source (path) is changed for a tool in a model
NIM036917; AddJoin is ignoring the qualifiedFieldNames environment at 9.3.

Tech supports last recommendation was to use a geodatabase for all the input data, rather than the old coverages.
So, I made up a file geodatabase into which I imported all the test data, using that for input into the model.

It didn�??t help.

It appears that we are not the only shop facing this problem.
In the now closed user forums is a five year old thread which indicates that ESRI has been aware of this since very early on.

For want of a better idea, I am attempting a crash course in Python but it will be quite some time before I can write anything approximating the complexity of the model.

Any advice would be appreciated.
As previously stated, we can�??t even consider migrating to a GDB environment until we can automate this analysis.

Thank you very much


G. Taylor