Yesterday’s issue was about queries reading dirty data without knowing it. This one is almost the mirror image: version 29 gives the Record data type a way to know, directly, whether it’s holding changes that haven’t been saved yet.
The Gap This Closes
AL has never had a built-in way to ask a record to instance a simple question: do you currently hold modifications that haven’t been written to the database. A developer working through a long procedure validating fields, running business logic, deciding whether to call Modify or Insert has always had to track that state manually, usually with a boolean variable set and cleared by hand at every point in the code where the record actually changes.
That approach works, but it’s fragile in a specific way: it depends entirely on the developer remembering to update the tracking variable at every single mutation point. Miss one, in a codebase with enough branching logic, and the tracking variable silently drifts out of sync with the record’s actual state. The bug that results is exactly the kind that’s hard to catch in review, because the code reads correctly it’s just tracking something that stopped being true three conditional branches ago.
What IsDirty Actually Does
Version 29 adds a genuine method to the Record API:
procedure IsDirty(): Boolean
It answers the question directly, from the record instance itself, rather than from a variable a developer has to maintain in parallel. Before deciding whether to validate, save, or otherwise process a record, code can now ask the record whether it actually holds unsaved changes, instead of trusting a hand-maintained flag that might have drifted.
Like several other v29 additions, this isn’t available on older runtime versions. Attempting to use IsDirty below runtime 18.0 throws AL0666, the same compiler error that gates ToolTip and several other recent Record and page capabilities behind a minimum runtime.
Where This Actually Matters in Real Code
The clearest use case is any procedure that conditionally decides whether a save is even necessary. A long-running batch process that touches many records, but only actually needs to persist a subset of them, can check IsDirty before calling Modify rather than calling it unconditionally on every record it touches skipping unnecessary database writes on records that were read, inspected, and left unchanged.
It’s also genuinely useful defensively, in code that’s grown complex enough that a developer can no longer be fully confident about every path a record has taken by the time it reaches a particular point in a procedure. Rather than trusting that every earlier branch correctly maintained a manual tracking variable, the code can just ask the record directly and get an answer that’s guaranteed to reflect its actual current state.
Finally
Neither this nor yesterday’s ReadState property changes how most existing AL code should be written. Both close a specific, narrow gap for the cases where the old default or the old workaround genuinely wasn’t good enough. IsDirty replaces a manually maintained boolean that could silently drift from reality with a direct question a record can answer about itself.
Leave a Reply