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

Anonymous User

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.

http://forums.esri.com/Thread.asp?c=93&f=1728&t=154673&mc=42

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

Regards

G. Taylor

street atlas-v10 labels ok.jpg

street atlas-v10 labels missing.jpg

forestknutsen1_2-1724085940004.png

Trisarahtops_1-1724085227879.png

justinperez

I understand that you will need to be more familiar with python... but my advice would be have your ending result, then build a simple python script (maybe model builder would work --- but it limits you much IMO) that does the gp.addfield and then do a gp.calculatefield to get the values from the fields with the database names prefixed to the new gp.addfields added fields.  Be comforted that all the arcgisscripting(9.3) works well.. good luck