Character Set
The character set decides which characters your database can store. The default is the one you want.
Where to find it
Architect Panel → Configuration:
- Site Settings — the option groups, grouped by subject
Architect Panel → Integration & Connections:
- Database Hosts — the databases themselves
What the default gives you
Full Unicode: every accented character, every non-Latin script, and emoji. It handles anything a user can type, which is the only safe assumption once real people are entering data.
The older four-byte problem
An older, narrower Unicode encoding shares almost the same name and covers most characters — but not emoji and not some less common ones. Text containing them is either rejected or truncated at the first one.
The symptom is characteristic: a record that saves fine until somebody puts an emoji in a note, then fails or silently loses everything after it.
Do not change it without a reason
It is set at installation and it is correct. Changing it on a database with data is a migration, not a setting — every text column has to be converted, and a conversion that goes wrong corrupts text in ways that are hard to detect and harder to reverse.
Symptoms of a mismatch
- Accented characters appearing as question marks or as pairs of odd symbols.
- Text truncated at the first emoji.
- Names that display correctly in one place and wrongly in another.
- Sorting that puts accented characters in surprising positions.
It has to match at every layer
Database, table, column and connection. A correct database with a mismatched connection produces exactly the same symptoms, and that is the layer most often wrong.
External data is where problems arrive
Imports, integrations and files brought in from elsewhere carry their own encodings. Data that looks corrupted after an import is usually an encoding mismatch at the point of import rather than a database problem.
Test with real names
Not with "test". Enter a name with an accent, a name in a non-Latin script, and something containing an emoji, and confirm each stores and displays correctly.
People’s names are not ASCII, and a system that mangles somebody’s name is telling them something.
Get it right before there is data
The whole point. This is a decision that is trivial at installation and a project afterwards.
Worked example
An organisation confirmed full Unicode at installation and tested with three deliberately awkward names before going live. An import from a legacy system later produced mangled characters, which was traced to the file’s own encoding rather than the database and fixed at the import.
Recommendations
- Keep full Unicode — the default is right.
- Never change it casually on a database with data.
- Check the connection layer, not just the database.
- Test with real, awkward names.