Creating domains
A domain is a named bundle of physical column attributes. This page covers creating a domain asset, filling in its entries, and checking what a domain change affects.
Creating a domain asset
Open Data Dictionary in the top menu, go to Data dictionary management and click New at the top left. Choose Domain as the kind and fill in the name, locale and description.

If you already have something to start from, use Store to pull in an official pack, or Import to restore one from a backup file.
The locale is fixed when the asset is created and cannot be changed later.
Filling in domain entries
Opening the asset shows the domain grid. Add rows with Add, or click a cell to edit it in place.
| Field | Description |
|---|---|
| Name | Required, and unique within the pack. |
| Type | Required. Picked from the shared type list and resolved to the real type of each DBMS. |
| Length and scale | Only filled in when the type accepts them. |
| Nullable | Required. |
| Default value and expression flag | Decide together whether the default is a literal or an expression. |
| Auto increment | Available only for types that support it. |
| Description | Note when this domain should be used. |

Type rules
- Entering a length on a type that takes none is reported right in the cell, and a type that requires a length cannot be left empty.
- A value above what the type allows is clamped to that maximum.
- Auto increment cannot be turned on for a type that does not support it.
- Shared types are resolved to a real type per DBMS, so one domain can be used from connections to different database engines.
Default value: literal or expression
A default value is in one of three states: not set, literal, or expression. An expression is picked from the standard function list or typed in directly.
- A literal is validated against the type, whether that is an integer, a number, true or false, or a date format.
- An expression is limited to what the type and the DBMS accept as a column default.
- Expressions that cannot be used on a non-nullable column are rejected as you type.
Checking the impact of a change
Editing a domain leaves the columns that use it out of step. The domain change impact screen scans the tables of the connection and collects every column that no longer matches. It only reports, and never applies anything on its own.

- Type, length and scale are applied by default.
- Nullability, default value and auto increment can legitimately differ per column, so they are applied only when you tick the checkbox.
- Columns whose domain can no longer be found are listed but never unassigned automatically.
- Tables whose metadata could not be read are reported separately and retried when you scan again.
While applying, a table that already has an auto increment column skips just that column. If a save fails the run stops there, and applying again continues from what is left.
Good to know
- Editing a value the domain governs (type, length, nullability and so on) directly on the column releases that column from the domain. A column outside the standard is simply a column with no domain.
- Official packs cannot be deleted or left. Clone one to edit it as your own asset.
- Edits take effect once saved, and must be published before they can be used elsewhere.