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

[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

[Anonymous User]

Original User: rdharles

If you could export your model to a python script and post it, we could get a better idea of your process.
There are ways around the filename/fieldname issue.

[Anonymous User]

Original User: Geraldtaylor

Thank you very much, perezstr.
When I get a better handle on Python, I'll try and work toward what you suggest.

rdharles

Attached is the model as exported to Python. (GDBModel7test.doc)
I also uploaded the AML, the function of which we need to duplicate. (wscalc13aml.doc)
It spells out the process in old command line Arc/Info, on the off chance that that will help.
I had to change both the extensions to .doc so that they would upload.

Any suggestions will be appreciated.

[RDHarles]

One thing that jumps out at me right away is the "AddJoin" tool.  That tool creates the filename.fieldname thing.
The "AddJoin" tool is also not like the old Arc Workstation "joinitem" command.  AddJoin is only temporary.
Take a look at the tool "Join Field" (Management toolbox) instead.

If you have to use the "Add Join", you need to follow it with the "Remove Join" tool before you do a "Copy Features".
This will avoid the filename.fieldname.

[Anonymous User]

Original User: Geraldtaylor

Mr. Harles

Thank you very much. That appears to do the trick.
I replaced the "AddJoin"s with "Join Field" tools and it seems to work.
I still need to do a lot of test runs to see that the the model yields the same acreage numbers as the old AML
but, right now, the signs are favorable.

Thanks again.

G. Taylor

One thing that jumps out at me right away is the "AddJoin" tool.  That tool creates the filename.fieldname thing.
The "AddJoin" tool is also not like the old Arc Workstation "joinitem" command.  AddJoin is only temporary.
Take a look at the tool "Join Field" (Management toolbox) instead.

If you have to use the "Add Join", you need to follow it with the "Remove Join" tool before you do a "Copy Features".
This will avoid the filename.fieldname.