topic Re: Feature Class to feature class failing on second iteration in Python Questions

Feature Class to feature class failing on second iteration

Zeke — Thu, 20 Nov 2014 21:18:04 GMT

I've got two feature classes, one with data for four counties, and one with data for just one of the counties. I extract data from these feature classes into new feature classes in other feature datasets via arcpy.FeatureClasstoFeatureClass. The calling code is the first code block below. The relevant code for extractFeatures() is in the second code block

The the new feature class names, and the expressions used to extract them, are in tables. However, although they seem identical,AllCounties runs fine, but Chatham fails with a 999999 Execute Error function. A typical expression would be something like "FCC" LIKE 'H1%'. I've printed out all the values and they seem correct. I don't see any essential difference between one run through the code and another.

Can anyone see what's going wrong here? Thanks.

# CALLING CODE

# tbls = dictionary of table name : feature dataset pairs

# extract features for all four counties

sfc = 'AllCounties'

tbls = {'BoundaryDefinitions' : 'Boundaries',

'TransportationDefinitions' : 'Transportation',

'HydroDefinitions' : 'Hydrology'}

for k, v in tbls.iteritems():

extractFeatures(k, sfc, v)

# extract features for Chatham County only.

sfc = 'Chatham'

tbls = {'BoundaryDefinitions' : 'ChathamBoundaries',

'TransportationDefinitions' : 'Chathamransportation',

'HydroDefinitions' : 'ChathamHydrology'}

for k, v in tbls.iteritems():

extractFeatures(k, sfc, v)

# in extractFeatures()
# get feature class name/extraction expression pairs
    tbl = os.path.join(targetGDB, tblnm)
    flds = ('Name', 'Definition') # field names in table
    defs = {}
    try:
        with arcpy.da.SearchCursor(tbl, flds) as rows:
            for row in rows:
                defs[row[0]] = row[1]   
    # print error message and return empty dictionary to prevent further processing
    except exception as e:
        s = '\n\tError: unable to retrieve values from {0}.\n\t{1}\n'
        print(s.format(tbl, e.message))
        defs = {}

    # data was returned from the definition table
    if defs:
        sds = 'Framework'
        src = os.path.join(targetGDB, sds, sfc)
        target = os.path.join(targetGDB, tds)

        for k, v in defs.iteritems():
            try:
                arcpy.FeatureClassToFeatureClass_conversion(src, target, k, v)
                print('\tExtracted {0} from {1} to {2}.'.format(k, sfc, tds))
            except Exception as e:
                s = '\tError: {0} not extracted. Halting extraction of {1} features.\n\t{2}'
                print(s.format(k, tds, e.message))
                break

Re: Feature Class to feature class failing on second iteration

XanderBakker — Thu, 20 Nov 2014 21:33:56 GMT

Just a question; in the first code block on line 15, is the feature dataset really called "Chathamransportation" or is there a "T" missing (ChathamTransportation)?

The error occurs on what line?

Kind regards, Xander

Re: Feature Class to feature class failing on second iteration

Zeke — Thu, 20 Nov 2014 22:48:05 GMT

Thanks Xander Bakker , that's just a typo when I copied the code over. The error occurs on line 24 of the 2nd code block.

arcpy.FeatureClassToFeatureClass_conversion(src, target, k, v)

When I've printed all the values, they all appear to be correct. The only thing I can think is that the sql expression, v above, is incorrect, but they're the same in the AllCounties version which does work. They come from the same tables.

Re: Feature Class to feature class failing on second iteration

XanderBakker — Thu, 20 Nov 2014 23:32:52 GMT

What is the query definition at the moment the code crashes?

# src: targetGDB\sds\sfc

# target: targetGDB\tds

# k: name

# v: where clause

# FeatureClassToFeatureClass_conversion (in_features, out_path, out_name, {where_clause})

arcpy.FeatureClassToFeatureClass_conversion(src, target, k, v)

I don't see anything strange in your code, but here are some questions/reasons for this to go wrong:

Is the output featureclass name unique in the geodatabase (no only in the feature dataset)?
Is the where clause correct?
Do you have a selection?
Does the where clause return results?

Re: Feature Class to feature class failing on second iteration

Zeke — Fri, 21 Nov 2014 13:28:55 GMT

Yes, the feature class name is unique. To be precise, it overwrites an existing one, but env..overwriteOutput is True
The where clause should be correct, since it works for AllCounties. Almost all the where clauses are in the format "FCC" LIKE 'H1%', (the letter/number changes for different feature classes). This string is stored in the Definitions field of the relevant table.
No selection, this is all done in a stand-alone script.
I guess I don't know if the where clause returns results. I don't know why it wouldn't, since it does for AllCounties, which has the same schema as Chatham. AllCounties is just a merge of Chatham and three other counties, all same schema.

If both AllCounties and Chatham failed I might have a path to understanding what went wrong, but since one works and the other doesn't, I'm at a loss. I've tried running Chatham first, but that doesn't work either.

Re: Feature Class to feature class failing on second iteration

Zeke — Fri, 21 Nov 2014 17:16:20 GMT

Xander Bakker‌, your first bullet point was actually correct. It didn't occur to me until just now, because I'd previously used a longer function that did rename the feature class. Didn't take that into account when I refactored the code. Once I checked and renamed k when sfc = Chatham, it ran fine. It would be nice if ESRI actually had a specific exception class for this, instead of handing it to a generic 999999 ExecuteError exception, but oh well. Thanks for your help.

Re: Feature Class to feature class failing on second iteration

XanderBakker — Fri, 21 Nov 2014 17:39:47 GMT

I am glad you figured it out and could resolve your problem. There are certainly a "few" enhancements that could be made with the exceptions. A generic error doesn't help much...

Kind regards, Xander