Macke in der Mailschablone ?

Zitat

NurNotes schrieb
Ein versuch mit fixup brachte die gleichen Fehlermeldungen.

Er schreit ja auch nicht nach einem Fixup sondern nach einem Compact

Gehe am Besten in den Administratorclient, wähle die DB aus und lasse sie mit Hilfe einer neuen Kopie komprimieren.

jemand hat/hatte der datenbank sicher die erweiterte einstellung "Spezielle Antworthierarchie nicht unterstützen" eingeschaltet. ist die eigenschaft aktiv werden die funktionen "@AllChildren" und "@AllDescendants" nicht mehr unterstützt. für eine maildatenbank darf die eigenschaft nicht gesetzt werden da die genannten funktionen in etlichen ansichten benutzt werden.

nach dem ändern der eigenschaft muss die datenbank komprimiert werden um die änderung wirksam werden zu lassen (genau das will dir die fehlermeldung sagen) eine neue kopie anlegen oder nur compact ausführen bringt gar nichts, wenn der haken noch gesetzt ist und mit übernommen wird.

am simpelsten ist es, wenn du statt über den client die datenbankeigenschaft neu zu setzen den compact das entfernen des falschen häkchens übernehmen läßt:

load compact mail/mueller.nsf -h

dabei wird automatisch mit hilfe einer kopie komprimiert. wichtig: die datenbank darf natürlich von niemandem geöffnet sein ;=)

Es scheint (unabhängig von dem Haken) noch ein Defekt in einigen internen Tabellen der DB vorzuliegen.

- updall -R (dann schauen obs geht) sonst weiter mit
- fixup (achtung, dabei könnten auch evtl defekte dokumente verschwinden. das läßt sich nur durch replikation mit einem älteren backup in dem die doks noch intakt sind beheben)
- erneutes compact, diesmal mit -c (wird aber evtl der selbige fehler auftreten wenn fixup nichts gebracht hat)
- neue replik (oder besser kopie, falls es keine repliken dieser db irgendwo gibt) anlegen

wenn das alles nichts hilft...nochmal melden ;=)

ps: ich geh mal davon aus, daß nicht etliche andre einstellungen der db geändert wurden. notfalls mal mit einer intakten db die eigenschaften vergleichen ;=)

die neue replik solltest du vielleicht nicht auf dem gleichen server anlegen - wenn der server per adminp mit sich selbst neue repliken anlegen will geht das ziemlich sicher in die hose ;=)

- versuch eine neue replik, z.b. auf deinem client

oder

- wenn es sonst nirgendwo weitere repliken dieser db geben sollte dann leg eine noteskopie dieser db an (das müßte sogar unter andrem namen auf dem server gehen)

- wenn das alles den fehler nach wie vor bringt dann sind mit ziemlicher sicherheit die internen verweise der bodyfelder zu den separat gespeicherten richtext- bzw. mime-objekten kaputt und die einzige mir bekannte lösung wäre manuelles löschen der defekten dokumente (bzw. anschließend vom backup zurückholen). welche dokumente das sind erfährt man aus dem log, da sind die note-id's aufgeführt.

- um zu testen ob der defekt noch da ist kann man mal ein im log genanntes dokument suchen und öffnen, vielleicht sinds ja auch nur verlorene anhänge, aber ich vermute die entsprechende mail wird sich nicht normal öffnen lassen (meine letzte erfahrung damit produzierte immer redboxes oder nsd)

- die defekten ansichten kann man versuchen zu beseitigen indem man einfach das design der mailschablone neu drüberspielt (mit db->gestaltung ersetzen)

so, dann viel erfolg erstmal...;=)

Dokument finden leicht gemacht:

- Admin-Client, Dateien, die Datenbank markieren
- Menü Werkzeuge, Datenbank, Dokument suchen
- ID (ohne die Nullen) eintippen

allerdings läßt mich die ausschrift oben "45CE GELÖSCHT daten note" vermuten, daß entweder fixup oder compact schon die defekten dokumente beseitigt haben und nur noch die deletion-stubs probleme machen. in dem falle sollte das beseitigen aller deletionstubs aus der db das problem lösen:

- Datenbank, Replizierparameter, Platzsparer
- Feld: Dokumente löschen die seit xxx Tagen nicht geändert wurden
- statt xxx eine 0 (Null) eintragen (ich nehme an vorher stand eine 90 drin, ist der Default-Wert) und, GANZ WICHTIG: NICHT den Haken vor der Zeile setzen. Also nur den Wert ändern!!!!
- Ok klicken

Das dauert jetzt nen Moment - er löscht dann die Deletionstubs.

Anschließend wieder die 90 reinschreiben (oder was eben drin stand)

Schauen ob jetzt alles i.O. ist

was findest du denn nun im admin-client wenn du wie beschrieben nach der note-id schaust? wie viele defekte sinds denn die noch gemeldet werden? sind noch ansichten betroffen? das replace design schon durchgeführt? wirklich mal eine noteskopie versucht? fragen über fragen die ich aus deinen antworten nicht herauslesen kann ;=)

ok...hatte ich nur falsch verstanden dann. aber was mir fehlt ist eine aussage zur noteskopie der db. dort treten doch nicht exakt die gleichen fehler auf? und auch vieviele dokumente das betrifft hast du nicht geschrieben.

aaah, ok, langsam kommt klarheit in die sache. ich hatte ja schon vermutet daß es was mit den gelöschten dokumenten zu tun hat. lediglich an die möglichkeit daß hier softdeleted dokumente noch im papierkorb liegen könnten hab ich nicht gedacht. ok, dann in der original-db mal den papierkorb leeren (in geh davon aus daß das was drin ist absichtlich gelöscht wurde). danach die datenbank-eigenschaft "softdeletions" (also wiederherstellbare löschungen) mal deaktivieren, anschließend das " spiel" mit der 0 und der 90 wiederholen. und die softdeletions dann wieder aktivieren und die 90 wieder rein. jetzt fixup, compact -c und updall -r wie schon gehabt.
meine andre frage nach der anzahl der betroffenen dokumente bezog sich übrigens aufs notes-log, da ja dort die defekte einzeln mit note-id aufgeführt sind.

du hast anscheinend meine antwort im papierkorb-topic (19.07.2004 11:42) überlesen sonst wüßtest du daß dein MANUELL keine auswirkung auf gelöschte dokumente bei R6 hat (oder hast du 5er mailtemplates?) die funktion löschen sorgt nämlich fürs echte löschen, nur werden xxx stunden (default 48, bei dir eben 4000) die dokumente noch von der physikalischen löschung verschont. nach ablauf der zeit...no way (außer backup)

fakt ist: die datenbank des nutzers ist nunmal kaputt - wenn du nichts unternimmst riskierst du daß noch mehr dokumente betroffen sind. notfalls muß man sich eben einen plan ausarbeiten wie man die im papierkorb liegenden dokumente so markiert daß man sie zurückholen, das problem beseitigen und wieder löschen kann. weiterhin würde ich meinen usern erklären daß der papierkorb kein normaler ordner ist. dann sollen sie sich einen müll-ordner anlegen oder archiv-db's.

betreffs zurückholen...wenn du kein backup hast siehts sehr schlecht aus.

.[d]das löschen übernimmt der compact task, dazu ermittelt er alle laut datenbankvorgabe (eben diese 48h normalerweise) abgelaufenen dokumente.[/d]

korrektur - siehe später in diesem thread.

der compact task sollte eigentlich auf jedem server 1x täglich, mindestens jedoch einmal wöchentlich laufen.

läuft der nicht (z.b. weil ihn niemand als periodisch auszuführen eingerichtet hat) dann werden auch verschiedene aufgaben nicht wahrgenommen. danach klingts bei dir, als wäre er nie eingerichtet gewesen und nur sporadisch von hand gestartet worden.