Database connections¶
Database connections let a process read from or write to an external database. Triggers, forms, and report tables use the connection.
Create a connection¶
- Open the process and choose Process objects → Database connections.
- Choose + New.
- Fill in the connection fields and save.
Saving with required fields empty reports each one under its own field with This field is required, aligned to the start of the input; read-only values are dimmed so it is clear they cannot be edited.
When you edit an existing connection, the UID field comes first — it is the identifier the process references, so it is worth checking before changing anything else.
Test the connection¶
Test connection checks the server, the port, the database, and the credentials without saving. The result is shown under a single heading rather than repeating the same message twice: either it connected, or it reports what failed.
Test again after changing the host, the port, or the credentials — a saved connection can still be unreachable.
Use the connection¶
| Where | What it can do |
|---|---|
| Triggers | Query the database and store the result in a variable |
| Report tables | Read lookup data |
| Forms | Populate dropdowns from a query |
The connection is defined per process, so two processes can point at different databases, or at the same one with different credentials.
Protect the credentials¶
- Use an account with the minimum access the process needs: usually read-only for lookups.
- Do not reuse a personal account; a service account survives staff changes.
- Treat the connection list as sensitive: anyone who can open the designer can see the host and the user.
Permissions¶
Designing a connection requires design permission for the process; using it at run time does not. See Permission reference.
Related¶
- Triggers — the usual consumer of a connection.
- Variables — where query results are stored.
- Case Tables — structured data kept inside the process, when an external database is not needed.