For an arcpy toolvalidation script, I have been trying to figure out a good way to detect ArcGIS layer files (*.lyr) based on "Query Layers", and to distinguish them from "normal" feature layers pointing to a File or Enterprise Geodatabase. I haven been searching fruitlessly through the ArcGIS for Desktop Help and especially the 'describe' object properties, and Google to see if there was any clear and easy way to do this, but I haven't found anything yet.

I am likely to have overlooked something obvious, but does anyone have ideas of how to do this?

The ultimate goal is to be able to restrict layer files selected by a user for a certain parameter of the script to those that are not based on a Query Layer, so to exclude them.


Unfortunately, there isn't currently a way to check whether a layer is a "Query Layer" just like you can with isRasterLayer, isNetworkAnalystLayer, and others. Provided we have an .mxd with a feature class added from the Catalog window (feature layer) and a query layer:

mxd = arcpy.mapping.MapDocument("CURRENT")
df = arcpy.mapping.ListDataFrames(mxd)[0]
lyrs = arcpy.mapping.ListLayers(df)[0]
#[<map layer u'FL_Areas'>, <map layer u'Q_Areas'>]

#u'Database Connections\\Zion@server.sde\\Zion.OWNER.Research_areas'
#u'Database Connections\\Zion@server.sde\\Zion.DBO.%Areas'


As you can see the Query Layer has the % sign in its datasetName. So checking is just about finding out

if "%" is in lyrs[1].datasetName

then it's a Query Layer.

  • Yes, this was my initial thought too, that there would be something like "isQueryLayer" to do this simple job. Thanks for the current suggestion. I am still curious though, if someone else may have found another way that is a bit more robust or logical, so will wait a bit for further suggestions. – Marco_B Mar 7 '16 at 20:15


Unfortunately, as far as I can tell now, the suggested workaround of testing for a "%" character in the the datasetName property of a layer, doesn't seem to work in a toolvalidation script.

Even worse, it seems that simple tests like


end in an exception in the case of Query Layers in toolvalidation scripts.

Of course, Query Layers do not have a "traditional" datasource, as it is just a generic SQL statement, that can pull its data from anywhere in a database even combining tables, or potentially being based on a spatial function creating derived geometries like a buffer operation.

So, the only thing I have currently been able to come up with for the specific case of toolvalidation, is to actually catch the exception using try/except, and then set a warning on the parameter in case an exception is raised stating an unsupported layer type was chosen.

This at least gives me the opportunity to exclude the Query Layers from being accidentally set as tool parameter, although I do consider this a pretty dirty hack for something so basic.

I am still all ears for a better solution...

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.