Das Notes Forum
Domino 9 und frühere Versionen => Administration & Userprobleme => Thema gestartet von: jdorr am 03.06.04 - 08:31:14
-
Hallo zusammen,
seit gestern morgen taucht folgende Fehlermeldung im Log eines Mailservers auf:
"Fehler bei der Aktualisierung der Ansicht '($Users)' in names.nsf: Feld ist zu groß (32K), oder die Spalten- oder Auswahlformeln der Ansicht sind zu groß"
Als Folge davon wurden keine Mails mehr zugestellt. Nach Überarbeitung der Ansicht ging es wieder, allerdings ist die Lösung eher temporär. Wir haben eine Mischumgebung mit 5er und 6er Servern. Hat jemand hier schon einmal diese Meldung gehabt?
Gruß
Jörg Dorr
-
Was habt Ihr denn "überarbeitet"?
Wieviele User stehen im NAB?
Steht die Meldung im Log eines R6 oder R5 Servers?
Fragen über Fragen...
Andreas
-
Hi,
die Meldung ist im Log eines 5er Servers erschienen und im Adressbuch stehen 637 Einträge . Aus der Ansicht haben wir folgende Spaltenwerte entfernt:
@Soundex(LastName) : (Lastname + " " + FirstName + " " + MiddleInitial)
@Trim(@LowerCase(
@If(@IsAvailable(ListName); @Trim(ListName :
Ist wie gesagt nur eine temporäre Lösung, bin im Moment etwas ratlos ???
Gruß
Jörg
-
Also, 637 Einträge ist ja sehr wenig. Daran kann es also nicht liegen.
An einer Systemansicht zu manipulieren, davon kann ich nur abraten. Ihr seid da in einer nicht mehr von IBM unterstützten Umgebung!
Wahrscheinlich hat die Ansicht einen defekten Index.
Habt Ihr schon mal einen
updall -r names.nsf
und ein
fixup names.nsf
gemacht?
Auch bietet sich mal eine Gestaltungsaktualisierung an. ABER vorher klären:
Haben Sie 6er Server ein R5 Design des Domino Directories? Oder wie habt Ihr die Mischumgebung gelöst?
Andreas
-
Yep, updall, fixup und Gestaltungsaktualisierung haben wir natürlich vorher gemacht ==> Problem bleibt bestehen. Das mit der Manipulation einer Systemansicht ist mir auch klar, allerdings war das die einzige und schnellste Möglichkeit den Betrieb aufrecht zu erhalten. Die 6er Server haben 5er Design (noch) und was noch interessant ist ein Kollege von mir hat zu Hause am Tag vorher das names noch repliziert (in dieser Names funktioniert die Ansicht). Wenn man die "defekte" Ansicht auf dem Server löscht und die funktionierende reinkopiert, ist der Fehler immer noch da, zieht man eine Kopie vom ganzen Adressbuch funktioniert es? Sieht mir irgendwie nach einem Problem auf Dokumentenebene aus. Na ja, wäre für jeden weiteren Vorschlag dankbar.
Gruß
Jörg
-
Dann würde ich den Server herunterfahren, die names.nsf dort löschen und eine funktionierende names.nsf kopieren.
Andreas
-
Vorher - oder zumindest interessehalber hinterher - könnte man mal ein Fixup und Compact bei abgeschaltetem Server über die betreffende NAMES.NSF laufen lassen. Da NAMES.NSF ja im laufenden Zugriff ist, hat das schon ab und an was gebracht.
Bernhard
-
Ist die letzte Option, da wir viele Aussendienst Mitarbeiter haben. Die müssten dann alles eine neue Replik über ISDN ziehen. Das alleine ist schon ein Problem für viele und das würde dann für uns etliche Stunden am Telefon bedeuten :-) Deswegen suchen wir noch nach einer anderen Lösung.
Gruß
Jörg
-
Halt, stop: Wieso müssen die Aussendienstler denn eine neue Replik ziehen ?
Du ziehst Dir auf OS-Ebene die NAMES.NSF von Server B und klatscht sie bei Server A wieder drauf. Da die NAMES.NSF untereinander ja Repliken sind, merken das Deine Aussendienstler überhaupt nicht.
Bernhard
-
Genau so wie Bernhard es sagt ist es. Die ADler merken davon nicht viel.
Andreas
-
@Bernhard,
gaaannz vorsichtig: Das Kopieren auf OS-Ebene geht gerade beim NAB häufig schief.
Dann lieber Notes-mäßig ne neue Replik ziehen (unter anderem Namen), Server runterfahren, alte names löschen und die neu gezogene Replik (dann OS mäßig) umbenennen.
Sonst macht der Server ne ellenlange Konsistenzprüfung, die er mitunter nicht gebacken kriegt.
Gruß Henning
-
Nun, das mit der OS Kopie klappte bei mir bis jetzt immer.
Man muss nur aufpassen, dass man aus versehen nicht die falsche ODS Version nimmt!
Also, nicht vom 6er Server die Kopie ziehen, wenn die DB 6er Format hat.
Der Vorschlag von HRaq hat den Vorteil, dass beim Erstellen der neuen Replik automatisch beschädigte Dokumente herausfliegen (meistens).
Andreas
-
Vielleicht hab ich mich nicht klar genug ausgedrückt. Das einzige names in dem der Fehler nicht auftritt ist eine Kopie einer 2 Tage alten lokalen Replik (Verwirrung total :-)). Eine neue Kopie auf dem Server bedeutet aber das der Aussendienst nicht mehr replizieren kann, sondern sich erst eine Replik der neuen Kopie ziehen muß.
Gruß und danke für die schnellen Reaktionen
Jörg
-
Egal, die lokale Replik ist genauso eine Replik, wie eine Replik auf einem zweiten Server.
Auch da gilt dann das oben gesagte.
-
Driri, er schrieb eben, es gibt nur eine intakte Kopie einer Replik.
Jörg: Dann müsst Ihr eben aus dem Backup eine funktionierende Replik ziehen.
Hast Du schon das comact und fixup bei nicht laufendem Server probiert ?
Bernhard
-
@Andreas,
dann hattest du Glück. Ich durfte dabei ganz andere (mitunter ziemlich negative) Erfahrungen machen.
War ja auch nur als Hinweis gedacht... ;)
Gruß Henning
-
Nochmal zur Ursache des Problems: Offenbar wurde in den letzten 2 Tagen ein Dokument erstellt oder geändert, welches mehr als 32 K in einem Textfeld enthält.
Es muss ein Dokument sein, das in der Ansicht ($Users) selektiert und in dem der Feldinhalt in einer Spalte angezeigt wird.
Ich würde mal auf eine Gruppe tippen. Sieh mal nach, welche Gruppen in der letzten Zeit erstellt wurden und wie groß in denen das Feld Members ist.
Du kannst dazu eine Kopie von $Users machen und eine Spalte einfügen, die nach dem letzten Änderungsdatum sortiert ist.
Andreas
-
@Bernhard :
Oops, mal wieder zu oberflächlich gelesen. Wenns allerdings ne OS-Kopie sein sollte, wäre es auch kein Problem.
-
Zitat Jörg:
Die 6er Server haben 5er Design (noch) und was noch interessant ist ein Kollege von mir hat zu Hause am Tag vorher das names noch repliziert (in dieser Names funktioniert die Ansicht).
Da er von "repliziert" spricht, dürfte es sich um eine Replik handeln.
Insofern dürfte mein Vorschlag, auch hinsichtlich der AD'ler, funktionieren.
Gruß Henning
-
Ich habe die Stelle nochmal herausgesucht:
Vielleicht hab ich mich nicht klar genug ausgedrückt. Das einzige names in dem der Fehler nicht auftritt ist eine Kopie einer 2 Tage alten lokalen Replik (Verwirrung total :-)).
Es scheint also wirklich nur noch eine KOPIE zu existieren, die funktioniert.
Bernhard
-
Ist doch schön, wenn sich Fragesteller klar und deutlich ausdrücken..... :o ;D ;)
Henning
-
Hallo zusammen,
nach langem Suchen haben wir den Fehler gefunden. In dem Feld short name einer Anwenderin stand dieser ungefähr 1000 mal untereinander (absolut keine Ahnung wie das passiert ist). Das Feld war dadurch > 32k. Inhalt korrigiert und schon klappt es wieder mit dem original Template. Trotzdem danke für die Resonanz
Gruß
Jörg
-
Da wart Ihr ja (okay, aus der Not geboren) extrem fleissig ...
Merkwürdig nur, wie das passieren konnte: "Eigentlich" hat der User bei korrekter ACL da ja keinen Zugriff, ausserdem meckert Notes schon beim Speichern. Gleiches gilt für Routinen in LS, die führen auch zu einem run-time error ...
Wenn Ihr da noch irgend etwas herausfindet, lasst es uns wissen - da hilft dann bestimmt auch anderen.
Bernhard
-
Hallo,
die User haben auch nicht das Recht Änderungen im Adressbuch vorzunehmen. Da wir Administratoren es auch nicht waren, sind wir jetzt auf der Suche nach dem Prozess der sowas verursachen könnte. Sobald ich was gefunden habe, geb ich euch eine Info.
Gruß
Jörg