+ Reply to Thread
Results 1 to 21 of 21

Thread: repeated AddField operations fails in 10.1, works in 10.0

  1. #1
    Tom Tyndall
    Join Date
    Jul 2010
    Posts
    19
    Points
    0
    Answers Provided
    1


    0

    Default repeated AddField operations fails in 10.1, works in 10.0

    The following code is throwing exceptions. The exception occurs at different places in the code; where it breaks on one run it may have successfully gotten past on a previous run.

    Here's the error I'm receiving:
    ExecuteError: ERROR 000464: Cannot get exclusive schema lock. Either being edited or in use by another application.
    Failed to execute (AddField).

    This code runs without issue under 10.0.

    Code:
    import arcpy
    import os, sys
    from xml.etree import cElementTree as ElementTree
    
    def addCoreFields(fc):
        arcpy.AddField_management(fc, "AssetObjectId", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "AssetId", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "AssetObjectStatus", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "Status", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "Feature", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "SubFeature", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "AssetCode", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "LaneLocation", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "Route", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "FromMilepost", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "FromOffset", "DOUBLE", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "ToMilepost", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "ToOffset", "DOUBLE", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
           
    if __name__ == '__main__':
        scriptPath = sys.path[0]
        dataGDB = os.path.join(scriptPath, "data.gdb")
        if arcpy.Exists(dataGDB): arcpy.Delete_management(dataGDB)
        arcpy.CreateFileGDB_management(scriptPath, "data")
    
        sr = "PROJCS['NAD_1983_StatePlane_Arizona_Central_FIPS_0202_Feet_Intl',GEOGCS['GCS_North_American_1983',DATUM['D_North_American_1983',SPHEROID['GRS_1980',6378137.0,298.257222101]],PRIMEM['Greenwich',0.0],UNIT['Degree',0.0174532925199433]],PROJECTION['Transverse_Mercator'],PARAMETER['False_Easting',700000.0],PARAMETER['False_Northing',0.0],PARAMETER['Central_Meridian',-111.9166666666667],PARAMETER['Scale_Factor',0.9999],PARAMETER['Latitude_Of_Origin',31.0],UNIT['Foot',0.3048]];-17746700 -44067300 3048;-100000 10000;-100000 10000;3.28083989501312E-03;0.001;0.001;IsHighPrecision"
        for name in ['one', 'two', 'three']:  
            fc = os.path.join(dataGDB, name)
            arcpy.CreateFeatureclass_management(dataGDB, name, "POINT", "", "DISABLED", "DISABLED", sr, "", "0", "0", "0")
            addCoreFields(fc)

  2. #2
    Mathew Coyle

    Join Date
    Feb 2011
    Posts
    1,370
    Points
    958
    Answers Provided
    150


    1

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Is it always the addfield function that breaks it or do other tools throw the same exception?

    In 10.0 I had a similar issue iirc with AddField. For some reason putting the parameters in a list and referencing those solved the issue. I may be misremembering though, it was several months ago now. I did read a post on here about 10.1 not releasing locks as fast as previously. Adding a Compact or Exists was the work around for it.


    Here's my code if you are interested.
    Code:
    def addfields():
        print "Adding fields"
        field_name_list = [field.name for field in arcpy.ListFields(calc_table)]
        add_fields = [
            ("TYPE", "TEXT", "#", "#", 40),
            ("ORIGIN_SITE", "TEXT", "#", "#", 10),
            ("UTYPE", "TEXT", "#", "#", 40),
            ("U_ORIGIN_SITE", "TEXT", "#", "#", 10),
            ("DEC_PER", "SHORT", "#", "#", "#"),
            ("LEAD_CON", "TEXT", "#", "#", 2),
            ("COV_GRP", "TEXT", "#", "#", 2),
            ("STRATA", "SHORT", "#", "#", "#"),
            ("CON_PIECE", "FLOAT", "#", "#", "#"),
            ("DEC_PIECE", "FLOAT", "#", "#", "#"),
            ("CON_VOLHA", "FLOAT", "#", "#", "#"),
            ("DEC_VOLHA", "FLOAT", "#", "#", "#"),
            ("UDEC_PER", "SHORT", "#", "#", "#"),
            ("UCOV_GRP", "TEXT", "#", "#", 2),
            ("ULEAD_CON", "TEXT", "#", "#", 2),
            ("TDASTRATUM", "TEXT", "#", "#", 8),
            ("UTDASTRATUM", "TEXT", "#", "#", 8)]
        for field in add_fields:
            if field[0] not in field_name_list:
                arcpy.AddField_management(
                    calc_table,
                    field[0],
                    field[1],
                    field[2],
                    field[3],
                    field[4])
    Mathew Coyle, EADA10
    GIS Analyst
    Alberta-Pacific Forest Industries Inc.
    ArcGIS 10.2.1 Testing
    ArcGIS 10.1 SP1
    Windows 7 SP1 64-bit

  3. #3
    Chris Snyder

    Join Date
    May 2010
    Posts
    1,262
    Points
    417
    Answers Provided
    38


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    I also had occasional issues with repetitive calls to AddField dropping the error:

    ERROR 000464: Cannot get exclusive schema lock. Either being edited or in use by another application.

    What I was able to ultimately deduce is that it was my virus scan software, which I assume, was identifying repetitive calls to AddField as "suspicious". As I recall, all of a sudden right after a McAfee upgrade, all my scripts started sporadically failing... All of them where the AddField was running in a loop. Upon disabling McAfee, the problem was solved.

    Possible solution: Try disabling/fiddling your virus scan software, or move to another virus scan software.

  4. #4
    Tom Tyndall
    Join Date
    Jul 2010
    Posts
    19
    Points
    0
    Answers Provided
    1


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Yes, its always the AddField tool that causes the problem. Your comment about not releasing locks fast enough is a dead on description of the behavior I'm seeing. I just tried inserting an arcpy.exist call between each addfield call to try and slow things down a bit but still the same problem. So to really force the issue, I inserted a python time.sleep call between each addfield trying first a tenth of second - same problem, a full second and fixed!

    Before your response, I put all those core fields in a template fc and use that for the initial schema definition. But I still have unique fields that get added to the created fc's and now with that extra second of execution time per added per field my geo proc just got a lot slower.

    Thanks for the help,
    Tom Tyndall
    Sr. GIS Programmer
    Arizona Dept. of Transportation

  5. #5
    Curtis Price

    Join Date
    Oct 2009
    Posts
    1,796
    Points
    874
    Answers Provided
    127


    0
    This post is marked as the answer

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Quote Originally Posted by tyndallt_esri View Post
    with that extra second of execution time per added per field my geo proc just got a lot slower.
    I suggest creating a template table or feature class in the in_memory workspace -- the Add Fields happen very fast with no file-locking issues -- and then you can use the in_memory dataset as a template for CreateTable or CreateFeatureClass to disk.

  6. #6
    Chris Snyder

    Join Date
    May 2010
    Posts
    1,262
    Points
    417
    Answers Provided
    38


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    in_memory workspace -- the Add Fields happen very fast with no file-locking issues
    ..DeleteField runs like a champ in_memory too.

  7. #7
    Tom Tyndall
    Join Date
    Jul 2010
    Posts
    19
    Points
    0
    Answers Provided
    1


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Curtis's suggestion about building and adding fields to an in memory feature class did the trick.

    Here's the final code. Thanks everyone.
    TT

    Code:
    import arcpy
    import os, sys
        
    def addCoreFields(fc):
        arcpy.AddField_management(fc, "AssetObjectId", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "AssetId", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "AssetObjectStatus", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "Status", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "Feature", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "SubFeature", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "AssetCode", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "LaneLocation", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "Route", "TEXT", "", "", "32", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "FromMilepost", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "FromOffset", "DOUBLE", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "ToMilepost", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
        arcpy.AddField_management(fc, "ToOffset", "DOUBLE", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
           
    if __name__ == '__main__':
        scriptPath = sys.path[0]
        dataGDB = os.path.join(scriptPath, "data.gdb")
        if arcpy.Exists(dataGDB): arcpy.Delete_management(dataGDB)
        arcpy.CreateFileGDB_management(scriptPath, "data")
    
        for name in ['one', 'two', 'three']:  
            fc = arcpy.CreateFeatureclass_management("in_memory", name, "POINT", "", "DISABLED", "DISABLED", "", "", "0", "0", "0")
            addCoreFields(fc)
            arcpy.CopyFeatures_management(fc, os.path.join(dataGDB, name))
            arcpy.Delete_management(fc)

  8. #8
    Chris Snyder

    Join Date
    May 2010
    Posts
    1,262
    Points
    417
    Answers Provided
    38


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Note that virus scan software leaves the in_memory workspace alone (since it's not on disk)...

  9. #9
    Tom Tyndall
    Join Date
    Jul 2010
    Posts
    19
    Points
    0
    Answers Provided
    1


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    I'd like to investigate the role that antivirus software has on this but I have no control over that environment, either on my workstation or on the ArcGIS Server machine, where this script is ultimately headed. Given the new problems I'm having regarding in_memory datasets I'm wondering if anyone has any further ideas on this problem?

  10. #10
    Chris Snyder

    Join Date
    May 2010
    Posts
    1,262
    Points
    417
    Answers Provided
    38


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Work around idea: Manually build the FC schema how you want it, and store it somewhere.... And then reference that "template" FC in the arcpy.CreateFeatureclass_management() tool, thus negating the need to run the AddField() tool.

    Question: What virus scan software are you running on your workstation? I noticed this issue with Symantec, upon switching McAfee it went away.

  11. #11
    Tom Tyndall
    Join Date
    Jul 2010
    Posts
    19
    Points
    0
    Answers Provided
    1


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    They're running Microsoft Forefront Endpoint on workstations and servers.

    The problem with the pre-built template is that I don't know what fields I'll be adding until run time. I'm reading through xml that defines the schema as well as carrying the data that will end up in the feature classes; and dynamically building the fc's based upon what I find in the xml.

    Click image for larger version

Name:	one.jpg
Views:	55
Size:	67.7 KB
ID:	17675

  12. #12
    Chris Snyder

    Join Date
    May 2010
    Posts
    1,262
    Points
    417
    Answers Provided
    38


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Well that makes it complicated...

    Dumb question: Is there any change in behaviour if you leave off the default parameters in AddField? For example:

    Code:
    arcpy.AddField_management(fc, "AssetObjectId", "LONG")
    #instead of
    arcpy.AddField_management(fc, "AssetObjectId", "LONG", "", "", "", "", "NULLABLE", "NON_REQUIRED", "")
    Is it possible to temporarily disable Forfront, and at least determine that doing so fixes the issue? Maybe your IT people will make an exception for you... mine did for me.

    FYI: I am running the following code in v10.1 SP0 (and actually running it as 16 seperate concurrent python.exe processesall at the same time using the subprocess module) and it is super stable.

    Code:
    #Process: Adds the neccessary fields
    arcpy.AddField_management(indxTileFC, "REMSOFT_ID", "LONG"); showGpMessage() #calcs this field in the post-process
    arcpy.AddField_management(indxTileFC, "ACCBUFF", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "ADMIN_NM", "TEXT", "", "", "20"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "COUNTY_NM", "TEXT", "", "", "20"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "CLASS_RPT", "TEXT", "", "", "8"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "CLASS_MODL", "TEXT", "", "", "8"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "DEFER_RSNS", "TEXT", "", "", "60"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "DEFER_YR", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "DFR_YR_MDL", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "DEM_ELV", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "DEM_SLP", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "DISTRCT_NM", "TEXT", "", "", "20"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "EAGLES", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "FORESTED", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "HCPLND_FLG", "SHORT"); showGpMessage() #added 20120827
    arcpy.AddField_management(indxTileFC, "HCPUNIT_NM", "TEXT", "", "", "20"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "ITERATION", "TEXT", "", "", "18"); showGpMessage() #edit made for Rod to QC 
    arcpy.AddField_management(indxTileFC, "LANDCOV_CD", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LANDUSE_CD", "TEXT", "", "", "12"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_NW_ID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_PC_ID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_SPS_ID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_E_FLG", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_F_FLG", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_I_FLG", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_S_FLG", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_DF_YR", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_RP_FLG", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LCL_UP_FLG", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LPU_CD", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LPU_NM", "TEXT", "", "", "30"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LSMS_RIP", "TEXT", "", "", "12"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LSMS_UP", "TEXT", "", "", "12"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "LYNX_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MGMT_FUND", "TEXT", "", "", "4"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_INT_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_MA_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_MA_NM", "TEXT", "", "", "50"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_PLN_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_PLN_LBL", "TEXT", "", "", "50"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_PLN_STA", "TEXT", "", "", "18"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_POL_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_POL_LBL", "TEXT", "", "", "50"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_POL_STA", "TEXT", "", "", "18"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_SWA_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_SWA_TNM", "TEXT", "", "", "50"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "MM_SWA_RSN", "TEXT", "", "", "75"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "NRF_DISP_O", "TEXT", "", "", "8"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "NSO_FH_OID", "LONG"); showGpMessage() #Future habitat areas
    arcpy.AddField_management(indxTileFC, "NSO_KC_OID", "LONG"); showGpMessage() #Kilickitat Core
    arcpy.AddField_management(indxTileFC, "NSO_KH_OID", "LONG"); showGpMessage() #Klickitat Habitat
    arcpy.AddField_management(indxTileFC, "NSO_MGT_CD", "TEXT", "", "", "3"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "NSO_MGT_CS", "TEXT", "", "", "21"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "NSO_MGT_AR", "TEXT", "", "", "8"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "NSOMGT_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "NSO_NESTP", "TEXT", "", "", "4"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "O_CMZ_TY", "TEXT", "", "", "2"); showGpMessage() #OESF CMZ buffer type (i or e)
    arcpy.AddField_management(indxTileFC, "O_CMZ_WTY", "SHORT"); showGpMessage() #OESF CMZ water type
    arcpy.AddField_management(indxTileFC, "O_OC_DIST", "LONG"); showGpMessage() #OESF distance to ocean (saltwater)
    arcpy.AddField_management(indxTileFC, "O_RB_DIST", "SHORT"); showGpMessage() #OESF riparian buffer distance
    arcpy.AddField_management(indxTileFC, "O_RB_OID", "LONG"); showGpMessage() #OESF riparian buffer objectid
    arcpy.AddField_management(indxTileFC, "O_RB_WTY", "SHORT"); showGpMessage() #OESF riparian buffer water type
    arcpy.AddField_management(indxTileFC, "O_SWS_ID", "SHORT"); showGpMessage() #OESF subwatershed identified
    arcpy.AddField_management(indxTileFC, "O_SWS_PCT", "FLOAT"); showGpMessage() #OESF percent of subwatershed in DNR's forested managment
    arcpy.AddField_management(indxTileFC, "O_SWS_UAC", "FLOAT"); showGpMessage() #OESF subwatershed upland acres (no saltwater) 
    arcpy.AddField_management(indxTileFC, "O_UNST_SRC", "SHORT"); showGpMessage() #OESF unstable slope data source
    arcpy.AddField_management(indxTileFC, "O_UNST_TY", "TEXT", "", "", "2"); showGpMessage() #OESF unstable slope type (i or e)
    arcpy.AddField_management(indxTileFC, "O_UNST_WTY", "SHORT"); showGpMessage() #OESF unstable slope water type
    arcpy.AddField_management(indxTileFC, "O_WET_TY", "TEXT", "", "", "2"); showGpMessage() #OESF wetland type (i or e)
    arcpy.AddField_management(indxTileFC, "OWLS_1R", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "OWLS_1R_E", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "OWLS_M1", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "OWLS_SW", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "PARCEL_ID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "PEREGRINES", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "PLS_OID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "PLS_SEC_NM", "TEXT", "", "", "20"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "PLS_TWNRNG", "TEXT", "", "", "8"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "REGION_NM", "TEXT", "", "", "20"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "RIU_CUR_ID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "RIU_MST_ID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "RMU_POLYID", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "ROAD_BUFF", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "ROAD_DIST", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "ROS", "TEXT", "", "", "8"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "ROS_ZN_CD", "TEXT", "", "", "2"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SHU_NM", "TEXT", "", "", "12"); showGpMessage() #added 20120905, csny490 - same as OWNGROUP field
    arcpy.AddField_management(indxTileFC, "SLPSTB_AC", "FLOAT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SOMU_CD", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SOMU_NM", "TEXT", "", "", "30"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SOMU_PCT", "FLOAT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SUB_CD", "TEXT", "", "", "8"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SUB_NO", "LONG"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SUB_PCT", "FLOAT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SUB_UP_AC", "FLOAT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SUR_OWN_CD", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "SUR_OWN_NM", "TEXT", "", "", "50"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "TIM_OWN_CD", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "TIM_OWN_NM", "TEXT", "", "", "50"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "WOGHI_INDX", "FLOAT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "WRIA_CD", "SHORT"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "WRIA_NM", "TEXT", "", "", "30"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "XACT_TY", "TEXT", "", "", "2"); showGpMessage()
    arcpy.AddField_management(indxTileFC, "XACT_OID", "LONG"); showGpMessage()

  13. #13
    Tom Tyndall
    Join Date
    Jul 2010
    Posts
    19
    Points
    0
    Answers Provided
    1


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Leaving off the default parameters didn't work, also tried mzcoyle suggesting about putting the field info in a list and iterating through the list when adding fields - similiarly, no work. What's happening in the showGpMessage call in the latest code sample?

    All the AV setting's are disabled; going to have to work the AV issue with IT before I can test it.

  14. #14
    Chris Snyder

    Join Date
    May 2010
    Posts
    1,262
    Points
    417
    Answers Provided
    38


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Bummer...

    showGpMessage() is just a logging function - sends the gp messages to txt file.

    Might be frustrating, but adding time.sleep(1) between calls to AddField() might be your best option for now... At least you know it works...

  15. #15
    Tom Tyndall
    Join Date
    Jul 2010
    Posts
    19
    Points
    0
    Answers Provided
    1


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    I got help with a workaround on the other side of this issue, so I'm back with an in_memory workspace.

    Thanks for all your assistance.

    Tom
    AzDOT

  16. #16
    Nathan Heick
    Join Date
    May 2010
    Posts
    78
    Points
    15
    Answers Provided
    0


    1

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    After two days of failure, I think I have diagnosed the problem with our ETL after migrating to ArcGIS 10.1. It seems that Microsoft Forefront is interacting with the files in the file geodatabase while our model and scripts are running, producing highly variable errors and corruption of the file geodatabase. I am calling Feature Class to Feature Class and Delete from these tools. The feature classes become read-only and locked and the errors are inconsistent. This was based on my own investigation.

    I decided to research the issue more and I found your Forum post. Thank you for validation. I wanted to add my issues to it and see if anyone had anything else to say about it. We have Microsoft Forefront on both our servers and workstations, so I have been able to reproduce the issue on both Windows 7 and Windows Server 2008 R2. I uninstalled Microsoft Forefront on my desktop and the issue was resolved. Any solutions that are workable with Microsoft Forefront? I will see if there are any settings I can adjust and post them here if they are successful.


    Thanks,
    Nathan

  17. #17
    Nathan Heick
    Join Date
    May 2010
    Posts
    78
    Points
    15
    Answers Provided
    0


    1

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    After two days of failure, I think I have diagnosed the problem with our ETL after migrating to ArcGIS 10.1. It seems that Microsoft Forefront is interacting with the files in the file geodatabase while our model and scripts are running, producing highly variable errors and corruption of the file geodatabase. I am calling Feature Class to Feature Class and Delete from these tools. The feature classes become read-only and locked and the errors are inconsistent. This was based on my own investigation.

    I decided to research the issue more and I found your Forum post. Thank you for validation. I wanted to add my issues to it and see if anyone had anything else to say about it. We have Microsoft Forefront on both our servers and workstations, so I have been able to reproduce the issue on both Windows 7 and Windows Server 2008 R2. I uninstalled Microsoft Forefront on my desktop and the issue was resolved. Any solutions that are workable with Microsoft Forefront? I will see if there are any settings I can adjust and post them here if they are successful.


    Thanks,
    Nathan

  18. #18
    Nathan Heick
    Join Date
    May 2010
    Posts
    78
    Points
    15
    Answers Provided
    0


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    After another day of troubleshooting and planning what to do, I at least learned that under the settings for Real-Time Protection, unchecking Enable Behavior Monitoring resolves my problem, but I cannot modify the system policy for all machines in the City. I'm wondering if Microsoft Forefront sees certain ArcGIS 10.1 behaviors as suspicious or interferes with the geoprocessing operations with its scanning processes. I don't see why this would start up at 10.1 versus 10.0. I'm guessing there might be a definitions update required from Microsoft. Technical Support is working on the issue, but I thought this was an important subject, so I wanted to leave an update for those who might benefit. I'm trying to avoid adding exclusions. I think Esri needs to identify why one version has trouble and not the other, and I think the solution should lie with the vendors on this one, not us changing our policies.

  19. #19
    Chris Snyder

    Join Date
    May 2010
    Posts
    1,262
    Points
    417
    Answers Provided
    38


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    Another possibly related virus scan issue: http://forums.arcgis.com/threads/254...l=1#post240540

  20. #20
    Nathan Heick
    Join Date
    May 2010
    Posts
    78
    Points
    15
    Answers Provided
    0


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    I'm still not 100% sure what is causing the problem, but it seems to only occur after repetitive calls to geoprocessing tools. Also, whenever it has appeared and I have tried disabling the antivirus software, that fixed the problem. I cannot consistently cause the problem by turning on the antivirus software, but turning it off does seem to fix the problem when it is there. Usually, the Delete tool appears to delete some of the feature class from the geodatabase metadata, but leaves the table files themselves and the feature classes appear as a tables in the root of the file geodatabase.

  21. #21
    Nathan Heick
    Join Date
    May 2010
    Posts
    78
    Points
    15
    Answers Provided
    0


    1

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    One behavior we did identify is that the problem seems to only occur when the file geodatabase is open in ArcCatalog. Previously, this was never a problem. I could watch the feature classes being deleted one at a time and ArcCatalog would refresh. It seems the combination of Microsoft Forefront and a shared lock being opened in ArcCatalog while accessing the file geodatabase locks the database from the same user who took out the shared lock, but not necessarily on every geoprocessing tool call, but some of them. Uninstalling Microsoft Forefront while doing this testing solved the problem. Reinstalling it did not recreate the problem immediately, but the problems only occur when the antivirus software is installed and Enable Behavior Monitoring is checked under Runtime Protection. Technical Support created a bug for this:

    Bug #NIM085826 Microsoft Forefornt/System Center2012 Endpoint conflicts with file geodatabase operations.

    Hope this helps someone searching.

  22. #22
    Nathan Heick
    Join Date
    May 2010
    Posts
    78
    Points
    15
    Answers Provided
    0


    0

    Default Re: repeated AddField operations fails in 10.1, works in 10.0

    I ran our ETL again on our new ArcGIS 10.1 Test Server. The problem appeared immediately 10 minutes into the ETL. I disabled Behavior Monitoring in Microsoft Forefront and the problem went away when I reran the tool.

+ Reply to Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts