I wrote and ran a simple script last year - it cycled through some line features, buffered them and then intersected with some other lines - it all worked fine.

I'm now trying to tweak the file to use a larger buffer, and it's not finding the database I am using to manage the loop and store the results.

This code:

rows = arcpy.SearchCursor("C:\\CEDAR_GIS\\SPEEDY3_GPS_DATA\\shapefiles\\Analysis\\Intersections.mdb\\final_to_school_routes_LINES") 

results in this error:

Traceback (most recent call last):
  File "C:\CEDAR_GIS\SPEEDY3_GPS_DATA\shapefiles\Analysis\GISbuff-GPSline_IntersectionTS.py", line 29, in <module>
    rows = arcpy.SearchCursor("C:\\CEDAR_GIS\\SPEEDY3_GPS_DATA\\shapefiles\\Analysis\\Intersections.mdb\\final_to_school_routes_LINES") #opens search cursor on Overlays_to_run
  File "C:\Program Files (x86)\ArcGIS\Desktop10.1\arcpy\arcpy\__init__.py", line 1133, in SearchCursor
    return gp.searchCursor(dataset, where_clause, spatial_reference, fields, sort_fields)
  File "C:\Program Files (x86)\ArcGIS\Desktop10.1\arcpy\arcpy\geoprocessing\_base.py", line 359, in searchCursor
    self._gp.SearchCursor(*gp_fixargs(args, True)))
IOError: "C:\CEDAR_GIS\SPEEDY3_GPS_DATA\shapefiles\Analysis\Intersections.mdb\final_to_school_routes_LINES" does not exist

But that table is in that database, and when I ran the script last year there was no error. I have since upgraded to ArcGIS 10.1 with SP1, which I think meant an upgrade to python. Has there been a change in the handling of .mdb files, or am I doing something stupid?

  • Make sure you don't have the table open in Access or some other program. – Jason Mar 6 '13 at 14:01
  • or even a leftover lock file – Brad Nesom Mar 6 '13 at 14:14
  • can you connect to it again after a reboot, and then it can't find the .mdb after running the same script again? If so then your script still has the connection open. You need to close the connection at the end of your script. – user12711 Mar 6 '13 at 14:27
  • I tried the script again after turning my computer on this morning (before opening anything else), and the same error was returned. If I use arcpy.Exists it returns true for the database, but false for the table. Presumably a lock file would be on the .mdb rather than the table within it? there doesn't seem to be one. – Flo Harrison Mar 7 '13 at 9:36
  • So, the script is working. in addition to installing SP1, I also installed the new 64-bit geoprocessing thing - this throws up the error, but if I run it in the old 32-bit way it runs fine. So, can I use my .mdb files with 64-bit processing? if so, how? – Flo Harrison Mar 7 '13 at 11:38

To my understanding, 64-bit background geoprocessing no longer supports personal geodatabases .mdb files. ESRI has a help resource that addresses the update to 64-bit processing. I believe running the script as a foreground process will default back to 32-bit processing (even with 64-bit background processing installed). This can be found at: http://resources.arcgis.com/en/help/main/10.1/index.html#/Background_Geoprocessing_64_bit/002100000040000000/

One user has tested the difference between 32 and 64-bit processing and found a marginal ~10% increase in processing speed on very large datasets. http://polygeo.com.au/2012/11/02/arcgis-for-desktop-10-1-service-pack-1-and-64bit-background-geoprocessing/

I hope this helps! I just discovered this site and wanted to help out the community.

|improve this answer|||||
  • 1
    Exactly this. The same thing with VBA in 10.1 or Excel in Linux support: a bunch of Esri software depends on Microsoft libraries that are Win32 (usually x86) specific and won't be ported by MS to newer platforms/architectures or updated except for security fixes. The writing for this particular .mdb issue was put on the wall with the not-so-new File Geodatabase (.gdb) format a few versions back. – Jason Scheirer Mar 8 '13 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.