Who Changed This Row? Engine-Level Audit Trails and the event_id Column

Every ERP argument eventually becomes the same question: who changed this, and when? Most systems answer it with triggers, or an audit table someone remembers to write to, or an application layer that stamps modified_by — until someone bypasses it.

DBX4 answers it in the engine. This post is about how, and about one column that most audit designs miss.

The usual four

Declare a table WITH PERFORMER and DBX4 adds four columns and maintains them itself:

CREATE TABLE po (id INT PRIMARY KEY, item TEXT, qty INT) WITH PERFORMER;

They're system-managed: hidden from SELECT * so they don't clutter your day-to-day queries, and creation stamps never move — an update touches updated_* and leaves created_* exactly where it was.

The fifth column: event_id

Four columns tell you *who* and *when*. They don't tell you which sitting.

If someone corrected fifteen part numbers during one login, updated_by says "jsmith" fifteen times and updated_at gives you fifteen near-identical timestamps. Reconstructing "what did that session actually touch?" means eyeballing timestamps and guessing.

So DBX4 mints an id at login and stamps it on every row that session writes:

EV-20260715040102-jsmith-1
   |             |      |
   |             |      +-- sequence
   |             +--------- user
   +----------------------- yyyymmddHHMMSS at login

Now the question is a query, not an investigation:

SELECT * FROM po WHERE event_id = 'EV-20260715040102-jsmith-1';

Three separate logins produce three distinct ids, so the trail survives even when the same person makes changes minutes apart. An update re-stamps event_id — it always names the session that last touched the row.

It applies to rich data too

The stamps aren't only for small scalar columns. A table holding a CLOB document, an XML metadata block and a BLOB image gets exactly the same treatment — replace the artwork and updated_by, updated_at and event_id all move together.

Why in the engine, and not the application?

Because application-level auditing is only as good as the code path. Every bulk import, every admin script, every "quick fix in the console" is a chance to bypass it. If the engine owns the columns, there is no bypass — the write and its attribution are the same operation.

Try it

The DBX4 Data Studio is live for approved users. Insert a row, update it from a different session, and watch event_id change while created_at stays put.

Comments (0)