Pulling information from a table into a parameter in a script tool

[VishalShah2]

Hello,

I am working on putting together a custom tool that helps populate information into four fields within each feature class in the database. The script is pretty straight forward and has no issues. My issue is I have to create 22 tools to do the same thing by each feature class and creating a value list in the parameters section of the script tool would be too cumbersome. Is it possible to have one table that can be automatically pulled right into a drop-down and the only thing I'd have to do is update that table whenever it needs to be updated?

[RandyBurton]

I am still trying to understand your initial selection.  My first thought was that the user would select something unique, like a project number, and then get the all other items that are associated with that project.  The project number would be a unique identifier for the row.

Perhaps you are needing something like a drill down selection.  That is, select an AsBuiltType, then select the AsBuiltCompany from a dropdown who is in that type group, and then continue refining the selection.

If your table looks like this (with 2 Type 1 entries):

Then your tool could present the 2 companies classified as Type 1.

Is this what you would like to accomplish?

[VishalShah2]

Randy,

While the drill selection would be nice, ideally, I'd like to provide all options in the column. So even if you select Type 1 in Document Type, the user would still get Company 1-4 in Document Company. The catch is this, this table will grow and there will be several entries that are the same in some fields. Can they be summed up in the validation of the script tool and then presented in the drop down menu?

[RandyBurton]

Would the ProjectID be unique?  If so, this would be the selection field, and the tool would pull the other fields on that row.  The important thing would be a unique ID that makes sense to the user.

The growth of the table should not be an issue, nor the duplication of entries.  The tool reads the table when it is first run and when the user makes a change.  You would want to make certain that wherever the tool is used, it will have access to the table.  Its location could be hardcoded into the tool, or you could add  a box in the tool where the user selects which table to use.

[VishalShah2]

The Project ID would be unique, but I'm not going for making a selection based on an unique entry. When the user opens the tool, I'd want them to have blank parameters and when they hit any drop down menu, it'll give them all of the entries within the table for the associated column. This is so that the user does not have to go in order to drill down or anything. Hopefully that made a bit more sense. Sometimes the user won't have the information for one of the parameters and so with that, they'd have to leave that parameter blank.

[RandyBurton]

What question would the user need to answer first?

[VishalShah2]

Are you referring which parameter the user would need to fill in first? If so, it wouldn't matter. Every parameter would have their own values and the user can enter in any order they'd like. Unless that isn't an option?

[RandyBurton]

If the user starts by selecting a non-unique identifier, like the AsBuiltCompany, then the tool would need to have the user drill down to select the unique row.  If the second selection was for ProjectID, then the tool would have a unique row and could populate the remaining choices.  To be able to code the tool, there would need to be a specific order to the selections the user makes.