Arcpy.Exists Fails On Existing Layers

[BrandonColeman]

I am running into an issue where the `arcpy.Exists()` function returns a `false` for a known good layer in the python interactive window.  We are using a map document template for the layers set up in the Table of Contents.

I usually would drag the layer from the Table Of Contents into the interactive window so it shows like `r'Work Layers\Replacement Tree'` since it is part of a group in the Table of Contents.  If I manually add in the data instead of use a template and resource the layers, the `arcpy.Exists()` function works and returns `true`, but on occasion, it will return a `false`.

When it returns `false`, I can check the layer's source, navigate to the location and specified feature class, and see that it is there.  I can add it in manually and run it, too. 

For some reason, it seems using an existing map document as a template and resourcing the Table of Contents breaks this on occasion.  The code I am using is a bit more complex than the `arcpy.Exists()`, but I have narrowed it down to that being the issue.  My code throws an exception saying a particular layer doesn't exist so that is the easiest way to troubleshoot.

I have even gone as far as to drag multiple layers from the Table Of Contents into a list in the interactive window and iterate over it with `arcpy.Exists()` to the same result of `false`.

I can set the workspace to the file geodatabase we're using and the using the feature class name (ie. `layer = 'Replacement Tree'`) links to the correct feature class.

Is there a bug or a disconnect somewhere when using a map document as a template and resourcing the data from the Table of Contents to the python interactive window so that layers (which show up on the data frame, too!) aren't connected as if they were added in manually?

Also posted to: file geodatabase - Arcpy.Exists Fails On Existing Layers - Geographic Information Systems Stack Exch...

[JoshuaBixby]

In situations like this, or really always, it is helpful to state what version (build number too) and patches you are running.

[BrandonColeman]

I am on v10.2.2.3552.

[JoshuaBixby]

I think I understand what is going on.  Whether it is a bug or not is for you to debate with Esri Support.

If you run the following on the problem MXD you talked about,

print arcpy.mapping.Layer(r'Work Layers\Replacement Tree').dataSource

I am guessing the results come back showing the original data source and not the re-sourced data source.

However, running the code below probably shows you the newly re-sourced data source:

mxd = arcpy.mapping.MapDocument("CURRENT")
lyr in arcpy.mapping.ListLayers(mxd):
    if lyr.name == r'Work Layers\Replacement Tree':
        print lyr.dataSource

In the second example, since you are retrieving the layers from the "CURRENT" MXD, it is showing you what is reflected in ArcMap currently.  With the first example, it appears to be going back to the MXD as originally loaded.

I haven't tried it, but you could try seeing if re-sourcing the data paths using ArcPy instead of the GUI makes Exists work the way you expect.  Is your script looping through the layers using arcpy.mapping.ListLayers?

[BrandonColeman]

Following your code check I did the following after setting mxd to the current map document...

>>> for lyr in arcpy.mapping.ListLayers(mxd, "*Replace*"):

...     print lyr.dataSource

...    

C:\***\*****\F_Geodatabase\*****.gdb\ReplacementTree

>>> for lyr in arcpy.mapping.ListLayers(mxd, "*Replace*"):

...     print lyr.dataSource

...     print arcpy.Exists(lyr)

...    

C:\***\*****\F_Geodatabase\*****.gdb\ReplacementTree

False

>>>

The layers are being re-sourced via another arcpy script already.  Trying to manually change it in the layer properties results in the same output.  In order to get it to work, I need to actually hit the add data button to put the data into the TOC.  That results in:

>>> for lyr in arcpy.mapping.ListLayers(mxd, "*Replace*"):

...     print lyr.dataSource

...     print arcpy.Exists(lyr)

...    

C:\***\*****\F_Geodatabase\*****.gdb\ReplacementTree

False

C:\***\*****\F_Geodatabase\*****.gdb\ReplacementTree <--Put in here by hitting add data button (same file)

True

>>>

The script that fails has a pre-built list of names to look for.  It was set up that way since the mapping team was repeating the same process over and over, so they just use a script to resource an existing mxd and save it as a new one.  If I can figure out why the simple arcpy.Exists() is failing, then I should be able to adjust the other parts.

Does that make sense at all?  I don't know how to tell if the mxd itself is corrupt is some manner, or if there is something I am completely missing.

[JoshuaBixby]

I am running ArcGIS 10.3.0.4322, and I don't see the issue you are having if I re-source a file geodatabases using arcpy or the GUI.  My original test used a SQLite database, and I think that was causing the issue for me, which makes me think it may be a client-datasource compatibility issue for you.

Have the geodatabases you are using been around for a long time, created in an earlier version maybe?  If so, does recreating the file geodatabases using your current version change the behavior.

[BrandonColeman]

The geodatabase is being created via an ArcObjects extension that copies an empty geodatabase that contains the general structure (blank feature classes) in it, and then it populates it using shapefile data that gets converted along the same (field name changes, etc).

There doesn't seem to be a problem there with the newly created geodatabase, or at least ArcMap/Catalog doesn't flag it as having any problems when opening it or the feature classes contained within.

This is kind of a sporadic problem though.  It only seems to happen on select mxd's.  So It may be a problem somewhere with the mxd that is getting re-sourced/copied?  I don't fully get why the re-sourced data in the TOC shows as non-existing when I can add the same data source again to the same TOC and that version is fine and exists.

[PiusHauenstein]

Which Release do you use for the client and the Geodatabase?

[BrandonColeman]

It all should be the same as my version, v10.2.2.3552.

[PiusHauenstein]

Otherwise it could be one of the known incompatibilites between Client and Server of different releases