@SetEnvironment and SetEnvironmentVar: Those "Environment Variables" Live in the notes.ini of Whatever Machine Runs the Code

To stash a setting from Formula or LotusScript, you've got a pile of look-alikes: @SetEnvironment, @Environment, session.SetEnvironmentVar, GetEnvironmentString. What they actually read and write is the notes.ini of the machine running the code — per-machine, not shared, not replicated. Plus a $-prefix rule that trips people up (Formula and LS prepend $ by default; reading a native notes.ini setting needs a flag). This piece pins down where they write, where the $ comes from, when to use them, and when to switch to a profile document instead.

The Unread-Marks Trap: They're Per-User, Not a Property of the Document

A document goes bold with a star beside it — the unread mark looks like a field on the document, but it isn't. It's one of the few things in Domino kept per user: your having read it doesn't mean anyone else has. Driving it from LotusScript with MarkRead/MarkUnread, it's easy to mark for the wrong user (an agent runs as one ID and only touches that ID's unread state); and unread marks don't replicate by default, so the server and your local replica routinely disagree on what's read. This piece explains the mechanism and three traps.

Execution Security Alert: That "Do You Want to Allow" Warning Is the ECL Guarding You

Run an agent, open a mail with a button, click a hotspot — and Notes pops an Execution Security Alert asking whether to allow it. That's not a virus; it's the ECL (execution control list) guarding your workstation. The ECL decides whether a given signer's code may run on your machine and what it can do; a signer not on the list, or one attempting an un-granted action, triggers the alert. This piece covers what the ECL is, why the warning fires, the difference between the workstation ECL and the Administration ECL, its relationship to signing, and how to set it.

Why Deleted Documents Come Back: Deletion Stubs, the Purge Interval, and Two Ways They Resurrect

You delete a document and days later it's back — not a haunting. In Domino a delete doesn't erase the document; it leaves a deletion stub, a marker that lets replication carry "this one was deleted" to the other replicas. Stubs get cleaned up on the purge interval (default 90 days). Documents "resurrect" for one of two reasons: the stub was purged before it replicated, or the same document was edited on one replica and deleted on another and the edit won. This piece explains the mechanism, both causes, and the settings that prevent it.

updall, fixup, compact: Which One to Run When a Database Is Broken, Bloated, or Its Views Are Wrong

Domino's three database-maintenance commands are the easiest to reach for blindly: run fixup because a view is stale, run fixup because the file got fat, run compact because it won't open — and get nowhere. Each treats a different illness: updall handles indexes (views / full-text), fixup repairs corruption (documents / structure), compact reclaims space (bloat). This piece sorts them by symptom, plus the official escalation order for corruption: updall first, then fixup, then compact -c.

Domino REST API 1.1.8 Released: Experimental CalDAV/CardDAV, New PIM Endpoints, and Cluster Failover

DRAPI 1.1.8 (2026-09-14) is out. This release brings experimental CalDAV/CardDAV/DXL Extension APIs (off by default), new PIM endpoints for mail attachment lists and calendar profiles, PIM reading mail from a cluster member when the primary is down, and fixes for Keycloak/OIDC key rotation. A few behavior changes are worth noting before you upgrade too — richTextAs defaulting to HTML, qrp/json requiring forms, the calendar-profile rename, and calendar entries needing date/timezone/duration — covered in the body.

Domino Server Troubleshooting: Before You Restart the Whole Server, Run These Console Commands

Something's off with the server — a feature stopped working, a task looks stuck, memory or disk is tight. The reflex is to restart the whole server, but that's blunt and wipes the scene. This piece organizes the most useful Domino console commands by the problem you're facing: show tasks to see what's running/stuck, show server for overall health, restart task <task> to restart just the one misbehaving task (e.g. restart task http, not the whole box), tell http show thread state to find a stuck thread, and dbcache show/flush/disable for the database cache. Look first, then decide what to touch.

XPages Save Conflicts: Why You Get One Even When You're the Only User

"Document has been saved by another user" — except no one else is touching the document, yet a save conflict shows up now and then anyway. This is an old XPages trap: mixing the dominoDocument data source's save with a back-end Document save on the same document makes Domino's conflict detection misfire and spawn a conflict document. Starting from the official conflict mechanism ($Revisions), it breaks down assono's classic reproduction and re-tests this 2013-era gotcha on both Domino 12.0.2 and 14.5.1.

NotesView AutoUpdate=False: Why Modifying Documents in a View Loop Slows Down and Throws 'Entry not found in index'

An agent loops a view, tweaks each document, and gets slower and slower — sometimes even throwing 'Entry not found in index.' The culprit: NotesView refreshes itself by default, so when your loop modifies the very documents the view indexes, the view keeps re-sorting under your feet — killing performance and invalidating your navigation position. The fix is one line before the loop: view.AutoUpdate = False. This piece explains the mechanism, the correct 'grab the next handle before modifying' pattern, and three side effects to know (snapshot, current-code-only, must Refresh to see updates).