nach Template-Wechsel Posteingang leer?

[schroederk]

Hallo,

bei einem User habe ich aufgrund eines Template-Problems, das Template serverseitig (load convert ...) auf ein anderes und dann wieder zurück gewechselt.
Nun hat der User (aber nur der User selber) das Problem, dass sein Posteingang leer erscheint. Die Mails kann er (nur) noch über Alle Dokumente finden.

Habt Ihr sowas auch schonmal gehabt?

Ich hatte ein solches Phänomen früher mal beim Wechsel auf die dwa7.ntf bei Personen, die schon sehr lange bei uns beschäftigt waren (und dementsprechend lange Notes hatten) Eventuell lag/liegt es an der ODS-Version?

[koehlerbv]

Bei einer der Aktionen ist der Folder ($Inbox) entfernt worden, später wurde ein neuer vom template hinzugefügt. Mit dem Löschen des Folders gingen auch all seine Inhalte verloren.
Das ist also vollkommen normal, so gewollt und "works as designed".

Bernhard

[schroederk]

Das kann ich nicht so recht nachvollziehen. Wenn ich auf ein komplett leeres Template wechsel und dann wieder zurück, ist der Posteingang bisher erhalten geblieben.
Bei Template-Problemen war es bisher mein eigenes Best Practice das Template zunächst zu überschreiben und wenn das nicht ausreicht vorübergehend auf ein leeres Template zu wechseln.
Zudem kann ich die Dokumente im Posteingang ja noch sehen, nur der User selber nicht.

[Tode]

Tja: da hattest Du mit deinen best practices einfach bisher nur Glück.
Denn die leere Inbox ist ein relativ häufiges phänomen, auch wenn ich gestehen muss, dass ich es in 8.5 lange nicht hatte.

Allerdings ist Bernhards Beschreibung nur eine mögliche Ursache. Aus Deiner Fehlerbeschreibung gehe ich eher von was amderem aus: ist die Inbox während des design replace gesperrt (weil der router grade ne mail reingelegt hat, oder der benutzer in dem moment drin steht, oder der indexer aus einem anderen grund geradevein update der Inbox macht, dann kann der convert sie nicht löschen. Trotzdem legt er eine neue inbox an. Du hast also jetzt höchstwahrscheinlich zwei inbox- Ordner in der Mailfile. Im client siehst Du das nicht, musst also mit dem designer ran: datenbank im designer aufmachen, einen der ordner umbenennen, und dann siehst du beide ordner und kannst die Inhalte zusammenführen. Bei gleichnamigen Ordnern ist es Glückssache, welchen der Client anzeigt, deshalb siehst Du die Inhalte, und der User nicht (ihr seht unterschiedliche inboxen). Auch in welchen der beiden ordner der router die mails ablegt ist zufall, auch wenn er immer den selben nehmen wird...

Wenn Du sowas machat also IMMER so vorgehen wie in der Hilfe beschrieben:
Tell router quit
Load convert
Load router

Und sichergehen, dass der client die Mailbox nicht offen hat (und auch sonst niemand).
Damit kannst Du das Risiko gut verringern....

[schroederk]

Hmm, ich hätte erwartet, dass ich die doppelte $Inbox auch sehen könnte, wenn ich mit STRG+SHIFT Go To... die Liste aller Ansichten öffne.
oder auch mit NotesPeek. Bei beiden wird nichts doppeltes angezeigt.
Auch im Designer kann ich keinen Fehler erkennen. (Was nicht heisst, dass da keiner ist  )

[Glombi]

Siehe dazu
http://www-01.ibm.com/support/docview.wss?uid=swg21104973

Example 3: Running the convert task (successful in one particular case)
If you run the convert task (convert -u mail\username.nsf inotes6 inotes6.ntf) on a mail file that has no $Inbox, convert will replace the design and then rebuild the Inbox:

Sample output:
datetime Mail Convert: Finished replacing design template in 'mail/username.nsf'
datetime Mail Convert: Started converting categories to folders in 'mail/username.nsf'
datetime Mail Convert: Building a categorized view
datetime Mail Convert: Checking for the maximum number of categories
datetime Mail Convert: Opening & repopulating existing folder '$Inbox'
datetime Mail Convert: Finished converting categories to folders in 'mail/username.nsf'

If no new mail is in the inbox, it is possible that the inbox is continuously caught in a corrupt state. Back up the mail file, delete the Inbox folder, and replace the design. This will add a new Inbox folder to the mail file (which will be empty at this point).

The convert task repopulates the inbox by copying into it all the e-mails received in the last three months. To prevent the convert task to repopulate the inbox and to to prevent it from converting the categories to folders you can use the -d option.

Andreas

[schroederk]

Vielen Dank für den Link. Nachdem nun neue Mails auch wieder im Eingang eintrudeln, werde ich diesen Agent schreiben, der die Mails, die sich in keinem Ordner befinden wieder in den Eingang schiebt.
Mal sehen, vielleicht auch gleich erweitern, dass man vorher die gewünschte Mail-DB auswählen kann, über die der Agent dann laufen soll.

Erstmal lieben Dank für die Hinweise, insbesondere dass ich meine Best Practice anpassen muss (auch wenn ich die letzen 999 Mal nie ein Problem hatte)

[schroederk]

Ich habe mir nochmal ein paar Gedanken gemacht, was den Template-Wechsel betrifft.

Wieso reicht eigentlich das Beenden des Router-Tasks, wenn doch der/die Benutzer weiterhin auf die DB zugreifen können? Müsste man nicht auch zuerst die Zugriffsberechtigung ändern und die User von der DB droppen?
Wie sieht es mit dem Zugriff durch den Traveler aus?

Bezüglich des Agents auf der IBM-Seite... Ich würde den Agent gerne vorher mal mit einer kleinen DB probehalber testen, wie könnte ich das Problem denn mal mit einer DB künstlich reproduzieren?
(Die zu korrigierende Original-DB ist 14GB groß)

[koehlerbv]

Lösch $Inbox mit dem Designer heraus und wechsel dann die Schablone.
Oder:
Entferne in der Kopie einfach alle Mails aus $Inbox - das hat ja den gleichen Effekt hinsichtlich des Agents.

HTH,
Bernhard

[MCPvsTron]

@schroederk
Korrekt, um ganz sicher zu sein sollten auch keine Anwender auf der Datenbank sein. Je größer die Umgebung umso mehr ist leider zu beachten, das geht dabei los das man an die Transactions Logs denken muss wenn man diese archiviert (bezüglich des Plattenplatzes) eventuelle Clusterrepliken, aktive Agenten in Mail-In DB`s und die Aktiviät der Anwender.
Wir machen so etwas nur am Wochenende, sperren den Zugriff für die Anwender und beenden vorher den Router. Wenn du ganz sauber sein willst und das verantworten kannst, geht das theoretisch ja auch wenn der Server offline ist.

VG
Christian

[schroederk]

Mich wundert, dass es da nicht vernünftige Boardmittel gibt um sowas zu bewerkstelligen.
Einfach eine Datenbank in einen Wartungsmodus setzen und schon haben User, Traveler, Router & Co keinen Zugriff mehr. Nur noch die Maintenance-Tools (fixup, compact, updall, convert, etc) von der Konsole aus.
Das würde die anderen Mitarbeiter nicht beeinflussen. Bei einer 14GB-DB z.b. einen compact -c durchzuführen ist blöd bei ausgeschaltetem router. Da staut sich dann doch zuviel. Und bis zum Wochenende (oder zumindest bis ausserhalb der Kernarbeitszeit) zu warten ist für den Anwender oft nicht möglich.
Das der compact dann einfach abbricht ist geradezu schon FAIL.

Noch ne Frage am Rande zur Ausführung von Agenten:
Wenn ich a) den Agenten in der Mail-DB habe, die physisch in USA liegt, und ich von Deutschland aus den Agenten starte, der Dokumente kopiert etc., werden dann die Dokumente über den Teich geschickt und wieder zurück?
Wie sieht es aus, wenn der Agent in einer physisch in Deutschland liegenden Mail-DB liegt und eine Mail-DB in USA "manipuliert"?

[MCPvsTron]

Wenn du einen Agenten im Vordergrund über deinen Client ausführst geht die ganze Kommunikation über deinen Client. Lässt du den Agenten im Hintergrund auf dem Server laufen würde die Kommunikation der Server durchführen.