Problem with UpdateCursor()

[IgorBalotsky1]

I am writing a simple script to test the updatecursor() function, and here is the code:

import sys, string, os, time, math, arcgisscripting
from datetime import datetime, date

gp = arcgisscripting.create()
gp.overwriteoutput = 1

testConnection = "Database Connections\\testConn.sde"

testTable = "sdeinstance.sde.UPDATE_TABLE"
layerName = "TEST_LAYER"

print "TEST0"
fc = testConnection + "\\" + testTable, "\"LAYER_NAME\" = '" + layerName + "'"
c4 = gp.updateCursor(fc)
print "TEST1"
r4 = c4.next()

The problem is that I keep getting an IO error that the reference to fc does not exist. I have triple checked the names and everything works fine. Maybe it's something simple; any ideas?

Thanks,
Igor

[BradPosthumus · Accepted solution]

In a cursor, the feature class and where clause need to be defined as separate variables. You currently have them in a single variable separated by a comma, which in fact creates a Python tuple.

Try using this format instead:

fc = testConnection + "\\" + testTable whereClause = "\"LAYER_NAME\" = '" + layerName + "'" c4 = gp.updateCursor(fc, whereClause)

[IgorBalotsky1]

In a cursor, the feature class and where clause need to be defined as separate variables. You currently have them in a single variable separated by a comma, which in fact creates a Python tuple.

Try using this format instead:

fc = testConnection + "\\" + testTable
whereClause = "\"LAYER_NAME\" = '" + layerName + "'"
c4 = gp.updateCursor(fc, whereClause)

I changed it to the above but now I am getting this error:

RuntimeError: ERROR 999999: Error executing function.

I think the original script worked in 9.3 but now I am running the same code in 10...could it be an issue with that?

Thanks,
Igor

[IgorBalotsky1]

Actually I tried it with a different table and the function worked - so the issue is maybe with the table permissions.

[IgorBalotsky1]

I found the issue! I created the table directly in SQL but when I created a similar table in ArcCatalog and referenced it in the script, everything worked fine. I guess it had something to do with creating the table directly in SQL.

[BradPosthumus]

Glad to hear you found the problem! I likely wouldn't have. 🙂