Lesezeichen auf DB geht nicht - geht - geht nicht

ich vermute das es hier an der desktop6.ndk liegt...diese ist stark mit den bookmarks verknüpft...entfernt ihr die desktop6.ndk regelmäßig oder macht ihr nichts damit?!

Das kann nur daran liegen, daß auf dem desktop (Arbeitsbereich / Kacheloberfläche) gar kein link zu einer entsprechenden replik liegt die ein anwender erreichen kann (nicht zu verwechseln mit zugriff haben).

Bookmarks sind leider schlichtweg *dämlich* bzw. kontraproduktiv, da sie nur auf eine replik-id zeigen und sonst gar nichts (es gibt ausnahmen aber die sind eben nicht die regel ).

das fällt nicht auf, solange eine datenbank nur auf einem einzigen server liegt bzw. maximal in einem cluster.
Sobald aber lokale repliken ins spiel kommen oder mehrere server wird es echt lustig und NIEMAND kann mehr genau sagen welche datenbank denn wann tatsächlich geöffnet wird.
(es gibt ein paar bookmark verfechter die dann mit so lustigen antworten wie "oberste kachel" oder "kommt auf den homeserver an" aufwarten und dabei leider vergessen daß das die bookmarks damit per se vollständig in frage stellt.

lange rede kurzer sinn:
bookmarks sind bei mehr als einer replik je anwendung nur mit gezieltem management des arbeitsbereiches / kacheloberfläche / desktop oder viel turnschuhmanagement (jede menge besuche vor ort) unter kontrolle zu kriegen...

wenn es sich nur um eine single replica umgebung handelt, dann muss irgendwas gewaltig schief liegen bzgl. der bookmark.nsf / desktop.dsk - letzterer fehlt dann jegliche information zu den "fehlerhaften" links in den lesezeichen.

falls interesse an gezieltem, transparentem und kontrolliertem link management (noch dazu ohne buttons ) besteht:
http://www.icodex.com/people

vlg flo.

Also diesen fehler kommt eher vom OS des domino servers als von etwas anders.
Höchstwahrscheinlich ist der server aus Linux oder Unix, und ist groß/klein schreibung das problem.
Beim ersten öffnen einer DB muß dieses korrekt geschrieben sein, beim weitere öffnen LEIDER nicht. Das ist ein Cache problem des servers, und NICHT eins des Clients.

StrawBarry: Ich glaube dazu das wir mittlerweile genug vom Icodex people gehört haben, und das 20 verlinkte postings mittlerweile genug werbung für einen NON-PROFIT webseite sind, oder zahle den Admin direkt für einer der werbebanner die auf jede seite oben stehen, dann brauchst du es auch nicht in jedes 3. posting von dir zu erwähnen. Ich bitte dich hier dann auch dieses zu unterlassen. Es gibt keiner hier im Forum die auf irgendwelche fragen ständig sein Eigenes Produkt wieder und wieder nach vorne bringt.

Hurga, da beuge ich mich natürlich dem Veto des "non profit" Moderators

vlg flo.
==================
Die neuesten Entwicklungen in Konferenzform, unter http://www.EntwicklerCamp.de oder http://www.B-KH.de zu finden.

Das ist leider ein Problem.. Es gibt für Linux ein kostenloses tool welches ALLE schreibformen vom dateisystem her auf kleinschreibung "korrigiert", dieses ist erstellt worden von Nash!com, und ist über seine Webseite (http://www.nashcom.de oder genauer hier) zu bekommen. Einfach einen email an ihm schicken mit deine anforderungen, ein schönen gruß von mir mitgeben (auch wenn dieses keinerlei positive oder negative nebeneffekte hat) und dann kannst du dieses tool auf dein domino server zusätzliche installieren.

Achtung.. VORHER solltest du die dateien ALLE auf OS ebene nach klein buchstaben konvertieren (ich hatte mal ein script dafür...) und ALLE datenbanken die "falsch" geschrieben waren den replications history löschen (sowohl auf der server als auch auf andere server in der Orga), sonnst verschwindet dieses problem nämlich immer noch nicht.

Das problem liegt einfach dadrin das Domino beim ersten öffnen einer DB dieses korrekt geschrieben braucht, und erst danach diesen DB in sein Cache aufnimmt, und genau diesen cache NICHT empfindlich ist für groß/klein schreibung. . . ABER beim replizieren dieser DB nach draussen er in den History die fehlschreibweise drin hat, und WEITERHIN dieses versucht (andere low-level call) und damit immer noch den DB nicht findet.
Also in klar text, es ist einiges an arbeit, und das nshextlo erlaubt das vernunftige arbeiten, mit nur sehr wenige einschränkungen.

Das behebt zugegebenermassen wirkungsvoll die Symptome und belegt gleichzeitig, dass clients eben mit einer -nicht existenten- Datenbank verknüpft sind.

Daniels Ansatz ist mit Sicherheit der wirkungsvollste - wenn auch nicht der sauberste, wofür allerdings er weniger was kann als vielmehr die IBM (da filebased case sensitivity von vornherein entweder vollinhaltlich oder gar nicht implementiert sein sollte).

Richtiger wäre mE Daniels Tool für eine Übergangszeit zu nutzen um während dieser Replication histories, Agenten und client links anzupassen und nicht einfach alles zu löschen was "ärger macht".

Einfach elementare Objekte (*.dsk, *.nsf) und Elemente (Repl History u.ä.) zu löschen wenn Sie "im weg herumstehen" kann meiner meinung nach nur ein ausweg sein, für den Fall daß es gar keine anderen möglichkeiten mehr gibt.

vlg flo.