docs(validations): the dropdowns support special missings

Both SOFTSELECT and HARDSELECT support them, and the dropdown lists them
alongside the ordinary values (no NaN entries for a numeric column).
This commit is contained in:
dc
2026-09-23 08:37:12 +00:00
parent e7fdb3ab52
commit abf01d6375
+3 -3
View File
@@ -59,11 +59,11 @@ The rules treat a special missing as a value for some checks and as a missing va
|CASE|Not applicable - it is a character rule.|
|ROUND|Ignored - ROUND only rounds values that are numbers, so a special missing is left as typed.|
|HARDREGEX / SOFTREGEX|Checked against the pattern like any other value. Unlike blanks and the plain `.`, special missings are **not** exempt. See [Regex Rules](#regex-rules).|
|SOFTSELECT|Passes - a soft dropdown never blocks a value.|
|HARDSELECT|Checked against the dropdown list like any other value - it passes only if the list contains it.|
|SOFTSELECT|Supports special missings - a soft dropdown never blocks a value.|
|HARDSELECT|Supports special missings - the value is matched against the dropdown list like any other value.|
|HARDFORMULA / SOFTFORMULA|The formula returns `#VALUE!` for that row instead of a number, and that is what gets submitted.|
In short, a special missing is **not supported** in a column that carries NOTNULL, MINVAL, MAXVAL or a formula. It is fine alongside the regex rules, a soft dropdown, and ROUND.
In short, a special missing is **not supported** in a column that carries NOTNULL, MINVAL, MAXVAL or a formula. It is fine alongside the regex rules, the dropdowns, and ROUND.
A primary key column is treated as NOT NULL whether or not the target table carries a physical constraint, and whether or not MPE_VALIDATIONS has a NOTNULL rule for it - a key identifies the row, so a blank and a special missing are both rejected there.