Skip to content

docs(PC0029): describe global variable tracing #184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Arthurvdv wants to merge 2 commits into
base: main
Choose a base branch
from
Open

docs(PC0029): describe global variable tracing #184

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c995f81
docs(PC0029): describe global variable tracing
Arthurvdv Sep 12, 2026
169155f
docs(PC0029): implicit primary key and TableNo OnRun receivers
Arthurvdv Sep 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion content/docs/analyzers/PlatformCop/PC0029.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,9 @@ linkTitle = 'PC0029'

When a new record needs a GUID primary key, the natural reach is `CreateGuid()`. Random GUIDs scatter values across the SQL index B-tree, causing page splits on every insert. At scale — bulk imports, high-throughput journal posting — this fragmentation degrades insert, read, and update performance by 20–40%.

This rule tracks the flow of `CreateGuid()` values through variable assignments and procedure calls (within the same module) to determine whether the generated GUID ultimately lands in a key field. Replace `CreateGuid()` with `Guid.CreateSequentialGuid()`, which produces partially-sequential values that keep index inserts append-only.
This rule tracks the flow of `CreateGuid()` values through variable assignments (local and object-scope variables of the same object) and procedure calls (within the same module) to determine whether the generated GUID ultimately lands in a key field. Replace `CreateGuid()` with `Guid.CreateSequentialGuid()`, which produces partially-sequential values that keep index inserts append-only.

The key check includes the implicit primary key of a table declared without a `keys` section, and the value is recognised however the record is reached — a named variable, `Rec` (tables, pages, request pages, and the `OnRun` trigger of a codeunit with `TableNo`), bare field access inside tables and table extensions, and `this`.

### Example

Expand Down Expand Up @@ -80,6 +82,7 @@ The rule does not flag the following scenarios:
- `CreateGuid()` assigned to fields in **temporary** tables (no SQL backing, so no index fragmentation).
- `CreateGuid()` passed as an argument to **event publishers** (idiomatic AL pattern for correlation IDs).
- `CreateGuid()` passed to procedures in **external dependencies** where the source code is not available.
- GUIDs returned from, or written to `var` parameters of, helper procedures are not traced back to the caller.

If you intentionally need a random GUID in a key field — for example, to prevent callers from guessing adjacent values in a public API — suppress the diagnostic with a pragma:

Expand Down