1. Run a parameterized example
This example uses the same six orders. The default region is North and the minimum amount is zero.
Start a second run with
region = South and minimum_amount = 25. Expect Games 30 and Garden 25. Run overrides do not change saved defaults.
Choose types and presence rules
A required parameter needs a supplied value or a default. A nullable parameter permits explicit
null. An omitted value and an explicit null are different inputs. An optional parameter without a default must permit its null result.
Use enum to restrict accepted values. For a string array, allowed values restrict its elements. Scheduled runs have no prompt, so their required parameters need defaults.
Decimals use JSON strings to preserve precision. Integers must fit signed 64-bit values; send values beyond JavaScript’s safe integer range as strings. Decimal precision is at most 38 digits.
Bind values in SQL
Writeregion = :region, without quotes around the binding. Parameters supply values, not table names, column names, or SQL fragments. Names starting with __ are reserved.
A delayed run keeps its logical scheduled timestamp. Use the window bindings to filter the intended period; see Data windows. Incremental workloads have separate parameter restrictions; see Incremental workloads.
Set query context
In workload details, set the shared catalog, namespace, time zone, case sensitivity, and ANSI checks. Apply the same initial settings to every task. Fully qualified table names reduce ambiguity when reading and writing across namespaces. The SQL time zone affects timestamp interpretation. The schedule time zone chooses cron boundaries. They are separate settings. Use UTC for the examples unless a lesson says otherwise. Worker reuse does not make session changes a reliable shared context. Save the intended initial settings on the workload. Use explicitSET or USE tasks for supported session changes within a run and connect their ordering deliberately.