Hiding a Database Design: Lock It Before You Ship a Template

You hand a template to a customer or install it on their server, and you don't want anyone seeing or changing the forms, formulas, and LotusScript inside — that's what hiding a database design does. Once set, in HCL's words it 'disables all design operations and hides all formulas and scripts': View > Design disappears, forms/views/agents can't be viewed or changed, formulas and code are invisible, and the design can't even be copied. This piece covers how it's done (via Replace Design with 'Hide formulas and LotusScript,' or inheriting from a template whose design is hidden), what it disables, why it isn't an encryption lock (it's not a permanent barrier to Designer/Manager users — pair it with the ACL), the point with no way back — there is no 'unhide,' so you must keep an unhidden copy of the template — and how hiding blocks agent changes, so use @Command[AgentEnableDisable].

Template Inheritance: Why Your Design Changes Get Overwritten Overnight

You change a form in a production database, and the next morning the change is gone — because that database has 'Inherit design from template' set, and the server's Designer task overwrote it overnight from the master template. This piece explains how Domino template inheritance actually works: what a master template is (an NTF with 'Database is a template'), how a database links to one via the Design tab's 'Inherit design from template,' how the design flows down through the server's Designer task (load design, runs daily at 1 AM by default, needs a replica of the template on each server), the difference between Refresh Design and Replace Design, and how to protect elements with 'Prohibit design refresh or replace' plus 'Propagate' — plus the practical traps: private agents/folders can't live in a template, and the icon/About/Using documents don't inherit by default.

NIFNSF: Move View Indexes Out of the NSF

An NSF bloats from two things: attachments (DAOS moves those out) and view indexes. NIFNSF (moving view indexes out of databases) handles the second — it moves a database's view indexes out of the .nsf into separate .ndx files, making the NSF smaller and backup/restore faster (an .ndx can grow to 1 TB). This piece covers what it does, why — like DAOS — it must have transaction logging enabled first, the ODS 51+ requirement, how to configure it on the Server document's NIFNSF tab in 12.0.2+ (versus the older notes.ini NIFNSFEnable / NIFBasePath / CREATE_NIFNSF_DATABASES), how to enable it per database with load compact -c -nifnsf on, and how to check with show dir -nifnsf — plus why enabling it with -c brings us right back to the DBIID rule.

DBMT: One Command Replaces Nightly compact, updall, and fixup

The maintenance-commands piece walks you through compact, updall, and fixup one at a time; but nobody types those by hand at 2 AM in production — the old way was a pile of Program documents running updall nightly plus a separate compact. From Domino 9, dbmt (the database maintenance tool) folds them into one: HCL says it 'relieves the administrator of the need to run the Updall task,' doing compact + updall + (when needed) fixup in a single task, with thread counts, a time window, and a compact-every-n-days cadence to pace it. This piece covers what dbmt does, how to run it from a Program document, the key compact-side options (-ct / -cnd / -tl / -range / -force) and updall-side options (-ut / -ftiNdays), and the one special case — -ods, which does a copy-style compact that reassigns the DBIID — and why that ties back to transaction logging and ODS upgrades.

Domino's Built-in Backup Task: Domino 12 Finally Ships Backup and Restore

Before Domino 12, database-level backup and restore meant wiring up a third-party tool (via the C API Toolkit). From 12, Domino ships Backup and Restore as built-in server tasks: one dominobackup.nsf configuration database lets you schedule backups and restore a single database on demand. This piece covers what it is, why — like DAOS — it must have transaction logging enabled first, how to build a config from the platform default in the Configuration view (the Main/Backup/Snapshot/Restore/Prune/Notification tabs), how to run it with load backup's switches (-b/-t/-i/-s/-p), and how to restore from the Database Inventory — including an easy trap: restoring outside the data directory reassigns the DBIID and invalidates the earlier transaction logs.

DAOS: Move Attachments Out of the NSF

The same attachment stored in dozens of documents, even across several databases, is how an NSF bloats. DAOS moves attachments out of the NSF and stores them, de-duplicated, as a single .nlo file on the server, leaving a reference called a 'ticket' in the document. This piece covers how it works (de-dup happens at save time, not in a later maintenance task), why you must enable transaction logging before it, how to set the Server document DAOS tab (base path, minimum size, deferred deletion) and add databases, and tier 2 moving cold attachments to S3; plus the reminder that after the attachments move out, you still compact the NSF to actually reclaim the space.

Domino Transaction Logging: It Replaces Routine Fixup

In the maintenance-command rules, 'is transaction logging on?' is always the branch that decides which option you type — with logging, don't run fixup routinely, compact with -b to keep the DBIID, and take a fresh backup after anything that changes the DBIID. But what is transaction logging, and why does it flip so many rules at once? This piece explains it: it records database changes into one log and replays it automatically on a crash restart, so logged databases need no consistency check (and no routine fixup); the three styles (circular / linear / archived) and their trade-offs; and why operations that rebuild a database (copy-style compact, fixup on a corrupt database, enabling logging) assign a new DBIID, invalidate the old log, and force a full backup.

XPages Performance: Why Computed Values Run Many Times per Submit

Drop a println in a computed value or a rendered formula, click a button once, and it runs five or six times — not a bug, but XPages running the whole JSF lifecycle on every submit, where a #{} (compute dynamically) value binding is re-evaluated every time it's read, adding up to several runs across the phases. This piece covers three knobs that cut that repetition: #{} (re-evaluated each time) vs ${} (computed once at load, static), rendered (in the tree, evaluated across phases) vs loaded (never built into the tree, skipped entirely), when to use each, and the ${} caveat.

What the true in document1.getDocument(true) Actually Does

In XPages SSJS you see both document1.getDocument() and document1.getDocument(true) everywhere, but what does that true (applyChanges) actually apply, when must you add it, and when is it just superstition? Getting the side wrong has real cost: omit it and you might save a document missing the values you just set in code; add it blindly and you don't really understand it. This piece sorts out getDocument() vs getDocument(true): true flushes the data source's pending changes (control input + programmatic setValue) into the backend document; in a normal submit the Update Model Values phase has already synced the on-screen values in, so it's usually redundant; you genuinely need true when you made programmatic changes or operate directly on the backend document. Plus the split with save() and getComponent().getValue().