- Axapta 3.0/4.0 keep a BATCH row per recurrence, so a failed run and the
next waiting run share a job key and gave two SQLI-AX-001 findings with the
same subject (the repository kept the last, the hub the first). The batch
rules now keep one finding per subject, the most severe.
- SQLI-AX-004 treated a single earlier 10-hour run as "normally that long"
and stayed silent; it now needs BatchHistoryMinimumRuns runs, like
SQLI-AX-002. A stuck job is SQLI-AX-004's finding only, not also -002's.
- Running(now)!.Value threw for an executing job with neither a start time
nor a first-seen time (and a negative duration meant clock skew); such jobs
are skipped.
- SQLI-AX-010 no longer calls every session in an AX database "from Dynamics
AX", and shows the raw CONTEXT_INFO as sensitive evidence.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Batch jobs: failed (001), longer than their own history (002), late or never
started (003), stuck in Executing (004). Number sequences: running out with a
forecast from SQLInsight's own samples (005), format shorter than HIGHEST
(006), blocked but still referenced (007), continuous and not cleaned up
(008). RecId running out, flagged far earlier for AX 3.0's 32-bit RecId
(009). AX user behind blocking from CONTEXT_INFO, honest where AX 3.0 cannot
tell (010). Subjects carry the database, so findings follow the hub opt-in.
SQL Scripts/<rule>.sql (and _collectors/) for every AX rule added or changed
in 1.4, incl. COM-AX-001..007: a Danish header plus the exact SQL SQLInsight
sends, generated from the code and checked by SqlScriptTests (rewrite with
SQLINSIGHT_UPDATE_SQL_SCRIPTS=1).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
