Wo speichert ein Condensed Directory Catalog, dass er Condensed ist?

[Tode]

Habe gerade folgendes interessantes Szenario: Ein Directory Catalog wurde dereinst als "Condensed" Directory Catalog angelegt.

Nun soll der aber ein "Vollwertiger" Katalog werden.
Bisher habe ich das immer so gemacht:
- Schablone auf pubnames.ntf wechseln
- Konfiguration anpassen
- lo dircat meindircat.nsf -r

Gut...
Dieser eine Katalog weigert sich aber beharrlich. Er "glaubt" weiterhin, er wäre ein Condensed Catalog, und in der Folge führt ein "lo dircat meindircat.nsf -r" zu der Meldung:

14.06.2013 11:48:06   Directory Cataloger finished processing meindircat.nsf: Directory Catalog has no Configuration record

Der Configuration record in einem pubnames- basierten Dircat ist ein Dokument der Maske "configuration", beim condensed dircat heisst die Maske anders, deshalb meine Vermutung, dass der dircat immer noch nach der "alten" Maske sucht.

Ich habe geprüft:

- Alle Dokumente (mit NotesPeak)
- Die Datenbank- Eigenschaften (DB- Typ ist "Verzeichnis")
- Das DB- Icon
- About this database / using this database

Ich habe eine Kopie ohne Dokumente und ohne ACL erstellt -> selbe Meldung.
Dann habe ich eine neue Datenbank mit der pubnames.ntf und gleichem namen erstellt -> Alles OK
Ich habe die Schablone bereits mehrfach hin und her gewechselt (auch leere Schablone ausprobiert)...

In welchem geheimen Flag könnte sich die DB diese Info merken?

[Tode]

Habe die Lösung selbst gefunden:
Es gibt zwei Masken und vier Ansichten, die zwar nicht geschützt sind, aber beim Schablonen- Wechsel trotzdem nicht überschrieben werden. Und scheinbar schaut der Dircat auf eines der Elemente: Ist es vorhanden, dann nimmt er an, dass es sich um einen Condensed Dircat handelt.
Ich habe die Elemente manuell gelöscht (aber jetzt nicht nachgeprüft, WELCHES Element genau die Ursache war), und jetzt lässt sich der dircat wieder neu aufbauen.