General technical specification

Definitions

Business Central uses Unicode to support multiple languages and special characters. NVarChar is the SQL-Server type for Unicode strings.

Terms:
string uuid (Universally Unique Identifier)
GUID (Globally Unique Identifier) - a Microsoft term.

AL Type	SQL Server Type	Notes / Behavior
`Code[x]`	`nvarchar(x)`	Always Unicode. Right-trimmed. Typically upper-cased automatically.
`Text[x]`	`nvarchar(x)`	Unicode. Preserves spaces.
`Text` (no length)	`nvarchar(max)`	Unlimited text length.
`Guid`	`uniqueidentifier`	Stored as 16-byte GUID.
`Integer`	`int`	32-bit integer.
`BigInteger`	`bigint`	64-bit integer.
`Decimal`	`decimal(38,20)`	Fixed precision decimal.
`Boolean`	`bit (tinyInt)`	Stored as 0 or 1.
`Date`	`datetime`	Date only; time portion = 00:00:00.
`Time`	`datetime`	Date part = 1753-01-01; time is used.
`DateTime`	`datetime`	Both date and time.
`Duration`	`bigint`	Internally stored as milliseconds.
`Option`	`int`	Stores the zero-based index of the selected option.
`Enum`	`int`	Stores the enum value’s integer ID.
`Blob`	`varbinary(max)`	Used for media, streams, or large data (images, docs, etc.).
`Media`	`varbinary(max)`	Same as BLOB but managed by system tables.
`MediaSet`	`varbinary(max)`	Same as Media, supports multiple files.
`RecordID`	`varbinary(20)`	Internal unique record identifier.
`TableRelation` (foreign key)	Matches underlying key field	Foreign key constraint may not exist physically but can be indexed.

Additional notes

All string types (Code, Text) use nvarchar — never varchar.
→ This ensures Unicode compatibility across all languages.
Business Central uses binary collations (e.g., Latin1_General_100_BIN2) for deterministic sorting and comparison, especially for Code fields.
Code and Text differ mainly in trimming and case handling:
- Code → trimmed, often upper-cased
- Text → preserves spaces and case
Fields with spaces or punctuation in their AL name (e.g., "Customer No.") appear in SQL as [Customer No_].

Business Central Definition (the built in AL programming language)

table 50100 "Example Table"
{
fields
{
field(1; "ID"; Guid) { }
field(2; "Code"; Code[20]) { }
field(3; "Description"; Text[100]) { }
field(4; "Amount"; Decimal) { }
field(5; "Is Active"; Boolean) { }
}
}

Note: Code fields automatically convert to uppercase in many contexts (depends on locale and BC version)

Corresponding SQL server results

CREATE TABLE [dbo].[Example Table]
(
[timestamp] rowversion NOT NULL,
[ID] uniqueidentifier NOT NULL,
[Code] nvarchar(20) COLLATE Latin1_General_100_BIN2 NOT NULL,
[Description] nvarchar(100) COLLATE Latin1_General_100_BIN2,
[Amount] decimal(38,20),
[Is Active] tinyint NOT NULL,
[SystemCreatedAt] datetime2(0) NOT NULL,
[SystemModifiedAt] datetime2(0) NOT NULL
)

Why `nvarchar`, not `varchar`?

Because Business Central supports Unicode across all languages and locales — Icelandic, Arabic, Japanese, etc.
That means Code and Text fields are always stored as Unicode strings (nvarchar), so you can store characters like “Þ”, “Á”, “ð”, “é”, etc. safely.

Collation and Sorting Behavior in Business Central

AL Type	SQL Type	Default Collation	Case Sensitivity	Space Sensitivity	Sort Order	Comments
`Code[x]`	`nvarchar(x)`	`Latin1_General_100_BIN2`	✅ Case-sensitive	✅ Space-sensitive	Binary	Fast, deterministic, strict
`Text[x]`	`nvarchar(x)`	`Latin1_General_100_BIN2`	✅ Case-sensitive	✅ Space-sensitive	Binary	Same as Code
(Older NAV, pre-BC15)	`nvarchar(x)`	e.g. `SQL_Latin1_General_CP1_CI_AS`	❌ Case-insensitive	❌ Space-insensitive	Linguistic	Slower, locale-dependent

What "Binary Collation" means

Business Central (from BC 15 / AL language onwards) uses binary collations in SQL Server:

Latin1_General_100_BIN2

That means:

Strings are compared byte-by-byte, not linguistically.
"A" ≠ "a" (case-sensitive).
"ABC " ≠ "ABC" (space-sensitive).
Sorting follows binary order, not dictionary order (e.g., “Z” < “a”).

This ensures deterministic and very fast comparisons — important for indexing, keys, and replication