outFeatureClass/arcpy.CopyFeatures_management

4123
13
12-29-2015 04:47 AM
CliveSwan
Occasional Contributor II

I need to automate a shapefile to feature class update. The problem is that the shapefile name and output (feature class) are not the same.

So I need to hard code the shp & features.

I have a loop that works, printing out the shapefile names.

The code fails when I try to use the arcpy.CopyFeatures_management function.

Can anyone see what is causing the arcpy.CopyFeatures_management function to fail??

Would appreciate a suggestion to resolve the issue.

import arcpy
import glob
import os
import sys
import csv
import time
import smtplib
import shutil
import ftplib


sdeConnection = arcpy.env.workspace = r"C:\database_connections\GIST.sde"
outWorkspace =sdeConnection

datadir = arcpy.env.workspace = r"\\server1\ER Shares\Highway_Layer_Update" ## URL works

try:
    #check file exists here
    fcList = arcpy.ListFeatureClasses()

    ## Feature classes are hard coded
    ## Feature classes are hard coded
    for i in fcList:
        if i == "Bus Stops.shp":
            #outFeatureClass = os.path.join(outWorkspace, shapefile.strip(".shp"))
            #arcpy.CopyFeatures_management(shapefile, outFeatureClass)
            print i  ## NO shp
            fcnew = "GISADMIN.KCC_BUSSTOPS_NEW"
            outFeatureClass = os.path.join(outWorkspace, fcnew )
            arcpy.CopyFeatures_management(i,  outFeatureClass)
            arcpy.DeleteFeatures_management(i)
        elif i == "Cluster_sites_2014.shp":
            print i            ## Prints shp
            fcnew = "GISADMIN.KCC_KHS_CLUSTERS_2014_NEW"
            outFeatureClass = os.path.join(outWorkspace, fcnew )  ## Fails
            printoutFeatureClass
            arcpy.CopyFeatures_management(i, outFeatureClass)
            arcpy.DeleteFeatures_management(i)
        else:
            print "No file"
except:
    print ("No File found program terminated")  ## This is printed out

Message was edited by: Dan Patterson I formatted your code to make it easier to read... use the syntax highlighting ... >> ... and select Python

0 Kudos
13 Replies
DanPatterson_Retired
MVP Emeritus

What's up with line 36?   printoutFeatureClass   perhaps print outFeatureClass

So you are saying that it failed.  Did you get an error message? and if so, what was it.

0 Kudos
CliveSwan
Occasional Contributor II

A typo,

I just printed out the except block message, not helpful.

Thanks.

0 Kudos
JamesCrandall
MVP Frequent Contributor

I'd try to uncover what the actual error is first.  You can either simply remove the try/except block and it should print the traceback, or just update your except to print the actual error rather than "No File found program termintated" (you will need to add another import statement with the code below...

import traceback

  try:
     'do stuff


  except:
      exc_traceback = sys.exc_info()
      print traceback.print_exc()
DanPatterson_Retired
MVP Emeritus

I agree with James.  People spend more time trying to debug try-except blocks...or worse interpreting them.   Having the listfeatureclasses within the try except block is an example.  If you had that line outside, followed by a print statement, you would at least know it got that far.  Also, a judicious use of print statements will allow you to see at each step whether a block succeeded.

CliveSwan
Occasional Contributor II

Hi James,

That provides a far more useful error message.

Thanks

Clive

JamesCrandall
MVP Frequent Contributor

As Dan mentioned, the try/except block can be a double-edge sword sometimes, especially at design-time.

I personally don't really employ them until I'm ready to build a test deployment version because I just want to see the tracebacks when they hit the Interactive Window (PythonWin).  Even then, the print or arcpy.AddMessage methods don't help much for much of my deployed implementations and I will typically use these try/catch blocks for writing out log events.

DanPatterson_Retired
MVP Emeritus

As an example...consider the variants of the simple script...

Header 1Header 2
# version 1
print(something)

Traceback (most recent call last):

  File "C:\Python34\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 326, in RunScript

    exec(codeObject, __main__.__dict__)

  File "F:\B_Python_3_\Python_1_to_edit\try_except_demo.py", line 1, in <module>

    print(something)

NameError: name 'something' is not defined

# version 2
try:
    print(something)
except:
    print("ooops")
>>> ooops
# version 3
import sys
import traceback
try:
    print(something)
except:
    exc_traceback = sys.exc_info()
    print(traceback.print_exc())

>>> Traceback (most recent call last):

  File "F:\B_Python_3_\Python_1_to_edit\try_except_demo.py", line 5, in <module>

    print(something)

NameError: name 'something' is not defined

None

Now...when developing scripts, I will leave it to the user to decide which is quicker in finding errors (dumb or otherwise) and which is the more informative

JamesCrandall
MVP Frequent Contributor

Great illustration.

I just started using the exc_traceback to simplify the error as I rarely need (or understand!) the error and line references to the actual modules/packages.  But most of the time I don't even have try/catch during development!

DanPatterson_Retired
MVP Emeritus

True... and since we have hijacked the thread, no one else cares and since you use pythonwin... the barebones error from the scriptutils.py script

("C:\Python34\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py")

tries to execute line 326.  Which I found was the line where...when everything else fails...pythonwin, finally tries to execute the script code using the variable from the dictionary

...

exec(codeObject, __main__.__dict__)

...

and of course, there is nothing in...

>>> locals().keys()
dict_keys(['__builtins__', '__loader__', '__doc__', 'pywin', '__name__', '__spec__', '__package__'])
>>>

called 'something'