Das Notes Forum

Domino 9 und frühere Versionen => Administration & Userprobleme => Thema gestartet von: masterste2000 am 04.12.06 - 10:52:13

Titel: Probleme in der Log
Beitrag von: masterste2000 am 04.12.06 - 10:52:13
Hallo Zusammen,

beim Sichten des Log´s bekomme ich immer wieder bei einigen MAIL-DB folgende Meldung:
Updating 'OutOfOffice' into database ' xyz.nsf

Zur Info:

- Cluster
- 5.0.13a Server

Warum? Woran liegt das? Was löst das aus?


VIELEN DANK
Titel: Re: Probleme in der Log
Beitrag von: Lossa am 04.12.06 - 16:27:07
Hi,

ein paar mehr Infos waren hilfreich:

- Wann gibt es dieses Meldung (Snippet des logs)
- Was für Tasks laufen auf dem Server zu dieser Zeit?

Die erste Vermutung, rein ins Blaue geschossen, das die Design Task dort nachts drauf arbeitet. Evtl. einmal prüfen ob alle Designelemente keinen Updateschutz haben, ausser die Ordner des Users.
Die Datenbank mittels convert oder manuelles Schablone wechseln einmal aktualisieren und prüfen ob in der nächsten Nacht der Designtask immer noch dieses Update macht.
Titel: Re: Probleme in der Log
Beitrag von: masterste2000 am 05.12.06 - 13:23:59
Habe gestern eine Änderung an der InBox vorgenommen.
An dem Agenten OOO wurde nichts verändert bzw. wurde nicht angefasst!
Daher finden die Änderung an der Inbox statt. siehe "Auszug aus dem Log".

Am Agenten ist "Durch Aktu./Ers. der Gestaltung nicht änderbar" nicht gesetzt.

Was mir aber aufgefallen ist, das dass Update nur bei den MailDB statt findet, bei denen der Nutzer erst vor kurzem den Agenten aktiviert hat.


Ich hoffe das sind ein paar mehr Info´s die helfen meine Frage WARUM wird eine Update durch den Designer durchgeführt? zu beantworten.


Vielen Dank





Titel: Re: Probleme in der Log
Beitrag von: Tode am 18.12.06 - 19:17:19
das ist ein Phänomen, mit dem ich mich schon lange abgefunden habe: Manchmal ist es so, dass Agenten
(ob OOO in der Mailfile oder beliebige andere in jeder Datenbank) bei jedem Design- Update aktualisiert werden (unter R5 werden die Agenten zusätzlich teilweise auch noch deaktiviert, das ist ein Spass....), obwohl sich nix geändert hat.

Nimm es einfach als gegeben hin,
mehr kann ich dazu nicht sagen.

Tode
Titel: Re: Probleme in der Log
Beitrag von: koehlerbv am 18.12.06 - 19:32:35
Was mir aber aufgefallen ist, das dass Update nur bei den MailDB statt findet, bei denen der Nutzer erst vor kurzem den Agenten aktiviert hat.

Das Aktivieren / Deaktivieren eines Agents stellt eine schreibende Aktion auf das Design-Element dar. Dadurch wird zumindest der entsprechende TimeStamp geändert. Und wenn dann der Design-Task darüberläuft, stellt dieser fest, dass da das Designelement "Agent OutOfOffice" nicht mit dem im Template übereinstimmt, ergo ... Works as designed.

Bernhard
Titel: Re: Probleme in der Log
Beitrag von: Tode am 19.12.06 - 09:25:26
so weit die Theorie @Bernhard...

Aber ich habe hier nicht nur eine (Test-) Datenbank, die bei jedem Refresh (ist ja gerade wenn man in der Entwicklung ist durchaus möglich, dass man alle 5 Minuten refreshed) einen oder mehrere Agenten als "Aktualisiert" in der Statusleiste angibt, obwohl weder der Agent selbst in DB oder Schablone noch eine zugehörige Script-Library verändert wurde.

Das passiert sogar, wenn man das Design refreshed und sofort danach nochmal refreshed: Jedesmal wird der Agent / werden die Agents (angeblich!?) aktualisiert.

Da dabei nix weiter passiert, hatte ich aber noch keine Musse, dieses Verhalten zu hinterfragen...

Meiner Erfahrung nach kommt das durch alle Versionen (erlebt mit R5, R6.5 , R7) vor, auch wenn es bei R5 am schlimmsten war, weil da auch Agenten sporadisch deaktiviert wurden, wenn sie in der Schablone deaktiviert waren.

Gruß
Tode
Titel: Re: Probleme in der Log
Beitrag von: Glombi am 19.12.06 - 09:49:43
Ob ein Agent aktualisiert wird, hängt meines Wissens mit dem internen Feld "$AssistVersion" zusammen.
Wenn man einen periodischen Agenten aktiviert/deaktiviert, sollte sich der Zeitstempel in $AssistVersion nicht ändern. Somit wird der Agent auch bei einem Design Refresh nicht geändert.

Das mal als erster Anhaltspunkt.

Andreas