An exported model to a script does not run

Description

Users develop large models based on complex workflows and export them to scripts. In many cases, these scripts fail.

Cause

Scripts exported by ModelBuilder occasionally have problems with names and paths that cause scripts to fail. The known behaviors are as follows:

A. The model has variable names that are 'Reserved Words' in the scripting language.

B. Input data is specified by a layer name in the model, not its full path.

Solution or Workaround

• A. Variable names contain 'Reserved Words'
  
  Most scripting languages have a number of 'reserved' words used in the basic syntax of the language that cannot be used by the programmer as variable names. In nearly all languages, words such as for, while, if, then and else are reserved, while words such as try and except are specific to individual languages, in this case Python. Using these words as variable names cause scripts to fail. To export the model to a script, avoid these words in the variable names. In addition, there may be other limitations associated with variable names. For example, Python does not allow variable names to start with numbers. Before exporting the model, learn the reserved words and the naming conventions for the scripting language and verify that the model name conforms.
• B. Input data is specified by a layer name in the model, not its full path.
  
  In Model Builder it is possible to supply input data to tools by dragging a layer from the ArcMap table of contents to the Model Builder window. When this is done, an input data variable, symbolized with a blue oval, is created in the model with the name of the layer. To see where ArcMap is looking for this data, double-click on the blue oval. The source of the data is the name of the layer in the ArcMap table of contents. This is acceptable in ArcMap because the application knows where to look for a complete path to the data and supplies this to the geoprocessing tools so they work correctly. However, when exported, a data variable based on a layer in the table of contents named 'MyShapefile' turns into the following line of python code:
  
  

  Code:
  MyShapefile = "MyShapefile"

  
  When the variable MyShapefile is supplied to a geoprocessing tool as the location of input data, the tool fails because it is not able to find any data at the path 'MyShapefile'. When geoprocessing tools are used in scripts, the tools need to know precisely where to find the data.
  
  There are several ways to work around this.
  
  One solution is to find each data variable name in the script and manually type in the full path to the data source. That is, in the script change:
  
  MyShapefile = "MyShapefile" to:
  
  MyShapefile = "C:/data/project/MyShapefile.shp"
  
  Avoid this task by verifying the model is pointing to the data specifically in model builder. To do this double-click on all the input data sources, the blue ovals, and navigate to the specific location of the data on disk. Once at the location on disk, the name of the blue input data oval changes to something similar to 'MyShapefile.shp'. Now when the code is exported to a script, the full path is specified in the script and it should work correctly.
  To view an example of how to do this, inspect the following model.
  
  Double-clicking on either of the blue input data sources reveals that both of these sources are references to layers in the ArcMap table of contents.
  
  When this model is exported to a python script, the 'local variables' and 'clip process' sections of the code only point to the name of the layer and do not specify the path.
  
  The code fails because the Clip tool is not able to find data at 'Downtown' or at 'Reedley'. As discussed, the solution is to go back to the model and navigate to the specific location of the data as shown in the following figure.
  
  Once this is done, the complete path to the data source is reflected when the blue data source oval is double-clicked. Now when the model is exported to a script, the full paths are included and the script works correctly.