topic Is it possible to automatically set a geodatabase location for all tools to store feature classes to in Model Builder without having to go into each tool and change the location? in ModelBuilder Questions

Is it possible to automatically set a geodatabase location for all tools to store feature classes to in Model Builder without having to go into each tool and change the location?

MichaelHutchison — Wed, 28 Mar 2018 15:23:01 GMT

I'm looking for tools in Model Builder to automatically change their output filegeodatabase to a created file geodatabase from earlier in the model. Right now I need to go into each and every tool and change the output geodatabase to the one created.

Re: Is it possible to automatically set a geodatabase location for all tools to store feature classes to in Model Builder without having to go into each tool and change the location?

JakeSkinner — Wed, 28 Mar 2018 19:18:49 GMT

Hi Michael,

You can reference an output variable using the name of the variable. Take a look at the graphic below. The model creates a an output geodatabase. I renamed this output by right-clicking on the oval > Rename > specified 'Workspace' as the name. I can then reference this output using %Workspace% in other tools.

For example, in the Feature Class to Feature Class tool I specify the output workspace simply using %Workspace%:

In the Get Count tool input, I can specify a feature class using %Workspace% as well:

This may be a good practice moving forward. You can simply change the name of a variable and it will reflect in any tool referencing that variable.

Re: Is it possible to automatically set a geodatabase location for all tools to store feature classes to in Model Builder without having to go into each tool and change the location?

DuncanHornby — Fri, 06 Apr 2018 15:53:04 GMT

If you go to model > properties you can set any environment setting for the whole model. Any tool in the model that uses that environment setting should inherit this, so in your case you would set the workspace environment setting. This is discussed here. This avoids having to create and manage inline variables as suggested by jskinner-esristaff (although technically there is nothing wrong with that approach, one could argue it is more transparent rather than a invisible setting).