jump to article
...intermittent thoughts

Notes 5 and 6 living in a harmony?

If you want to have Domino 5 and 6 Server in production, you have to be very careful about your domino directory - sure. Today I learned that a simple replication settings change in the NAB on the R5 Server is not enough.

After upgrading the complete infrastructure of a remote location of a customer to R6, we disabled the replication of forms and design elements for the NAB to prevent replacement of the R5 NAB design. Usually that schould be all to run Domino 5 and 6 in together. But today I learned, that that's not really all: the replication of both locations were including one document which replicated simply all available databases. So we had one replication which replicated even the design templates. After a regular design task run at night - the great Domino 6 template was placed at the R5 NAB.

So be careful and disable replication of the Domino 5 NAB template (pubnames.ntf) after each update or upgrade of your Domino Servers

How I learned to love the Notes UNK

In the last days I had some trouble with the beloved Lotus Notes UNK. The good news is, I know a lot about that tiny acronym now. The bad news is, there's now a lot of work to do...

So, what is the UNK?

The UNique Key Table is a Lotus Notes system table, residing in EVERY Lotus Notes database. It holds all the fields, you have in a database as list. In addition to the 'known' fields some so called overhead fields are listed here. these are fields, used by notes for several system purposes, necessary for the run time of Notes databases. If you think you have never seen the UNK, you are likely wrong: If you choose a field from fieldlist in the Domino Designer or from the reference list there, you get exactly that UNK shown in the windows.

What's now the problem?

Well, last week or so I got a little messagebox telling me: "Cannot store document, database has too many unique field names", while I was replacing a design with a newer version of its template. I was not very fearful about it and nearly automatically switched on the "Allow more fields in database" flag. But then my brain 'started a background task' and so I thougt all over the night about it. Next day I looked something around in the web and so I got some information.
  • Notes produces that message, when UNK is getting larger than 64 k
  • when UNK is larger than 64k, a lot of replication errors occur, since the target database may not be able to store documents
  • when using "more fields in database" option, FulltextIndex may not work correctly, especially searches by field or form do not work correctly (Great!!!)
  • the UNK is rebuild on a compact of a database so the UNK decreases in size, when fields are removed from database and a compact is processed. But... the UNK rebuild is only done, when database is NOT full text indexed and the compact is done in copy style mode (use load compact -c at the server console)
And how to fix it?
Well there are some tipps, which are really useful:
  • Abbreviate fieldnames: yes a good idea, but have you ever worked in an application which has around 2000 Fields and try to code with fields like "cbstatmc"?
  • use same name fields: yes, really a god tip, I will recognize it in future, but who has time to recode an application which is that complex to have too many fields...