2026.09.2 — Audit and Login Table ALTER Scripts

This page is unlisted — it is not linked from the sidebar or search, and is intended to be reached only via a direct link from the 2026.09.2 release notes.

Who needs this

This script is only relevant if your Apinizer installation writes Audit Records or Login Records to a relational database via the SQL/JDBC connector (Oracle, MySQL, PostgreSQL, or SQL Server) — that is, if log_AuditEvent and/or log_LoginLog is one of your configured log targets for those two screens.

If you use the Elasticsearch or MongoDB connector, skip this page entirely — those targets already carry the new fields without any manual step.

What changed

Apinizer 2026.09.2 adds the request-context fields that Audit Records and Login Records already show on screen — who made the request, from where, and how related records correlate with one another — to the relational Audit Event and Login Log tables as well.

log_AuditEvent gains six columns:

• event_type — which of the Audit Records event types this row is.
• outcome — SUCCESS, FAILURE, or DENIED.
• client_ip — the client's real IP address.
• user_agent — the User-Agent header sent by the client.
• correlation_id — ties this record to the request's other log entries.
• source — the front door the request came from (Management Console, APIops, API Portal, or System).

log_LoginLog gains three columns: user_agent, reason_code (the machine-readable reason behind a failure, lock, or password event), and target_project_id (the project a session moved to, for a project-switch event).

Not optional to defer

Unlike the traffic-log ALTER scripts on this site, these two inserts are unconditional — there is no "skip the column if it is missing" fallback. If you upgrade to 2026.09.2 without running this script first, every Audit Event or Login Log row your installation tries to write to that relational table fails, and is caught and logged as an error rather than crashing the request that produced it:

• An Audit Event write that fails this way still falls back to your configured failover connector, so the underlying event is not necessarily lost — only delayed or rerouted, depending on your failover setup.
• A Login Log write that fails this way has no failover — the row is dropped entirely. A failed sign-in, a session logout, or a password event that should have reached this table simply never arrives there.

New installations are unaffected: the CREATE TABLE statements on the Apinizer Log Table Creation Commands page already include all nine columns.

When to run it

Run this once, against each configured SQL/JDBC database that receives Audit Event or Login Log records, before the 2026.09.2 upgrade — because the write path is not fail-soft here, running it "during" the upgrade risks a window where records are already being dropped. Test in a non-production environment first if you use a change-control process for DDL.

If your installation only sends one of the two record types to a relational database (for example, Audit Records to Elasticsearch but Login Records to a SQL database), you only need to run the ALTER statement for the table you actually use.

Oracle

ALTER TABLE log_AuditEvent ADD (
    event_type VARCHAR2(32),
    outcome VARCHAR2(16),
    client_ip VARCHAR2(64),
    user_agent VARCHAR2(512),
    correlation_id VARCHAR2(255),
    source VARCHAR2(32)
);

ALTER TABLE log_LoginLog ADD (
    user_agent VARCHAR2(512),
    reason_code VARCHAR2(64),
    target_project_id VARCHAR2(255)
);

MySQL/MariaDB

ALTER TABLE log_AuditEvent
    ADD COLUMN event_type VARCHAR(32),
    ADD COLUMN outcome VARCHAR(16),
    ADD COLUMN client_ip VARCHAR(64),
    ADD COLUMN user_agent VARCHAR(512),
    ADD COLUMN correlation_id VARCHAR(255),
    ADD COLUMN source VARCHAR(32);

ALTER TABLE log_LoginLog
    ADD COLUMN user_agent VARCHAR(512),
    ADD COLUMN reason_code VARCHAR(64),
    ADD COLUMN target_project_id VARCHAR(255);

PostgreSQL

ALTER TABLE log_AuditEvent
    ADD COLUMN event_type VARCHAR(32),
    ADD COLUMN outcome VARCHAR(16),
    ADD COLUMN client_ip VARCHAR(64),
    ADD COLUMN user_agent VARCHAR(512),
    ADD COLUMN correlation_id VARCHAR(255),
    ADD COLUMN source VARCHAR(32);

ALTER TABLE log_LoginLog
    ADD COLUMN user_agent VARCHAR(512),
    ADD COLUMN reason_code VARCHAR(64),
    ADD COLUMN target_project_id VARCHAR(255);

SQL Server

ALTER TABLE log_AuditEvent ADD
    event_type NVARCHAR(32),
    outcome NVARCHAR(16),
    client_ip NVARCHAR(64),
    user_agent NVARCHAR(512),
    correlation_id NVARCHAR(255),
    source NVARCHAR(32);

ALTER TABLE log_LoginLog ADD
    user_agent NVARCHAR(512),
    reason_code NVARCHAR(64),
    target_project_id NVARCHAR(255);

Verification

After running the script, perform an action that produces an Audit Record (for example, save any asset) and confirm the row carries the new columns:

SELECT id, audit_event_date, principal, event_type, outcome, client_ip, correlation_id, source
FROM log_AuditEvent
ORDER BY audit_event_date DESC;

Then sign in to the Management Console once and check the Login Log row:

SELECT id, log_timestamp, source, principal, event_type, user_agent, reason_code
FROM log_LoginLog
ORDER BY log_timestamp DESC;

For new installations no action is needed — the CREATE TABLE statements on the Apinizer Log Table Creation Commands page already include the columns.