Edit-parameter
A Parameter is a user-defined value substituted into statements as %u:name%.
Contents
Creating a parameter
- Open Author → Parameters.
- Click the create button above the list.
- Fill in the fields below and click Save.
Fields
| Field | Notes |
|---|---|
| ID | Assigned automatically; read-only. |
| Name | Mandatory and unique. Maximum 100 characters; letters, digits, space and _, -, /.
|
| Description | Free text. |
| Connection | The connection used to evaluate the query. Leave as - None - for a parameter that only has a default value. |
| Default value | Maximum 2000 characters. |
| Query | An SQL statement returning the value. Only shown once a connection is selected. |
The Query field appearing only after a connection is chosen is the single thing most likely to cause confusion here. To create a query-based parameter, select the connection first.
Static or query-based
- Leave Connection empty for a static parameter — it always resolves to its default value. Suitable for values that differ between environments but not between runs, such as a schema name or a file path.
- Set a connection and a query for a query-based parameter, whose value is obtained at planning time.
The Add variable button beside the query lists the placeholders available in it. These are the scenario-level placeholders, so a parameter can be derived from the state of previous processings. See Placeholders.
When the value is taken
Query-based parameters are evaluated once, when the processing is planned — not per task, and not again during the run. The value is therefore fixed for the whole processing, which keeps a long run internally consistent but means a parameter cannot carry information between tasks.
Only the parameters actually used by the tasks in the scenario are evaluated.
The values resolved for a given run are visible through Show processing details in the Monitor console.
Practical notes
- Keep a default value on query-based parameters where a sensible fallback exists. A parameter that resolves to nothing substitutes as empty rather than failing visibly.
- Names are global. Parameters are not scoped to a scenario, so a name like schema will not stay unambiguous. Use a qualified name.
- Quote in the statement, not the value. Substitution is textual and unquoted. Prefer passing parameters as procedure arguments over concatenating them into SQL — see Placeholders#Quoting.
- Only the default value is available where a parameter is used in a scenario planning query, since the processing does not yet exist at that point.
