Posts by ciwu

    Mailitem im Ordner DvArchivePersonalDrafts erstellen.

    Nach Zuweisen der Eigenschaften (kein Send... aufrufen):

    Code
    // Delphi/Pascal
    MailItem.Save(EmptyParam, DvMsgSelDirect);
    S := MailItem.Fields.Item('FileName').Value;
    S := 'tic://' + S + '.001';
    ShellExecute(0, 'open', PChar(S), nil, nil, SW_SHOWNORMAL);
    
    // Warten bis Fenster aufgeht, dann kann man Folgendes machen:
    MailItem.Delete;

    Danach kann Anwender Editieren usw. und Senden oder Abbrechen drücken.

    Code
    DvApi32.Account accountl;
    DvApi32.Archive archive;
    DvApi32.DavidAPI davidapi = new DvApi32.DavidAPI();
    
    account = davidapi.Logon("server", "", "", "", "", "NOAUTH");
    archive = account.GetArchive("\\\\server\\david\\archive\\user\\12345678\\in");
    
    Console.WriteLine(archive.MailItems.Count);

    Das geht nach wie vor.

    "DvISE Object API 1.0 Type Library" importiert?

    Zwischenzeitlich Rollout 415 oder David-Client-Updates installiert?

    Ansonsten: "Sicherheitssoftware" aktiv?

    Oder mal VS 2022 probieren.

    Ausgelöst werden soll die ganze Aktion (Verschieben + Weiterleiten) aber von Hand, wenn man auf einer bestimmten E-Mail steht?

    Könnte im David mit einem User-Script gehen, welches einen Button in die Leiste oben einblendet.

    Siehe X:\DAVID\Code\scripts\COMMON.VBS usw.

    Hier eine einfache Verteilung aller selektierten E-Mails im Eingangsordner an ein konkretes Archiv mit Rückfrage pro Eintrag.

    Das Objekt MailItem müsste auch eine Methode "Forward" haben, wenn ich mich recht entsinne.

    Einfach in Dvapi32.chm nachsehen.

    Gelöst!

    Scheint mit den alten SIDs zusammengehangen haben.

    Nach Korrektur der (ab Rollout 407 im System-Protokoll aufgelisteten) alten SIDs verbindet sich die Smart-Client-App nach Serverneustart ohne o.g. Workaround.

    Die im Nutzereigenschaften-Dialog angezeigte SID änderte sich übrigens nicht nach Neuzuweisung des Windows-Accounts. Die alte SID wurde wohl intern irgendwo noch geführt, ohne dass man dies mitbekam - deshalb wohl nun auch die Anzeige im Log.

    Sieht man die mehrfachen Eingänge auch mehrfach im Eingangsprotokoll im David-Admin?

    Dann hätte diese ja der Grabbing-Server tatsächlich mehrmals abgeholt.

    Muss ja erst abholen und dann den DELE-Befehl senden. Wenn das Abholen gelingt, das DELE aber im Nirvana verschwindet, ist die Mail beim nächsten LIST/RETR wieder dabei.

    Steht die E-Mail nur einmal im Protokoll, dann fällt mir auch nichts weiter ein.

    Verteilregeln mit Zirkelbezug?

    Die Prüfer sollen mehrere David-Nutzer sein?

    Sonst könnten ja die wartenden E-Mails im Kontext des Prüfers in den Transit gestellt werden.

    Die Transit-Mail liegt im Out-Verzeichnis des Absenders.

    Wenn dort Schreibzugriff für die Prüfer existiert: soweit gut.

    Ich vermute in den "Pseudo-Ordner" Transit des aktuellen Nutzer kommt es nur mit der von Dir erwähnten Option.

    Möglicherweise könnten auf das Unterverzeichnis des Service-Nutzers unterhalb "X:\DAVID\Archive" mehr NTFS-Rechte gesetzt werden, so dass dieser im Client im Baum unter "Servername\Users" auftaucht, wo man sich dann zu "Out" durchhangeln könnte.

    Direkte Manipulationen an NTFS-Berechtigungen würde ich allerdings nur als "letztes Mittel der Gewaltanwendung" ansehen und dann auch nur nach vorheriger ausgiebiger Prüfung in einer Testumgebung.

    Nun ja, Windows-Updates gibt es schon ewig jeden Monat.

    Ja, auch da wird es manchmal schlimmer.

    Mein Kommentar bezog sich auf die hier geäußerten Unmut über zu niedrige Updatefrequenz in letzter Zeit.

    Und zu Beginn der Rollouts (oder Sitecare?) stand da wirklich - nach meiner Erinnerung - "aller 14 Tage" und "überraschen" und so etwas macht mir Angst.

    Die Anwender sind mit monatlichen Designänderungen usw. überfordert.

    Ich hab nichts gegen monatliche Bug-Fixes - eine Art "rolling release" ohne Trennung von Bug-Fix, neuen Features (mag noch gehen) und GUI- oder Verhaltensänderungen in einem Paket generiert nur unnötigen Supportaufwand - und zwar nicht bei Tobit.

    Dass die Meldung der Altlasten-SID sinnvoll ist und zur Lösung meines Smart-Client-Problems führte, habe ich ja bereits geschrieben.


    Wenn mir David nicht (mehr) gefallen würde, würden wir es nicht (seit Faxware unter Novell) heute immer noch einsetzten.

    Da war scheinbar doch vor einigen Jahren mal ein Neuaufsetzen des Servers.

    Die gemeldeten SID waren nicht alle Nutzer sondern die "alten". Die nach dem Umzug neu angelegten Accounts wurden nicht bemängelt.

    Habe über den Drei-Punkte-Knopf die Nutzernamen erneut ausgewählt, angezeigte SID änderte sich nicht. Beim nächsten Neustart kamen aber keine SID-Meldungen mehr.

    Außerdem scheint das auch die Ursache für meine Probleme mit dem smart client gewesen zu sein.

    siehe dort

    Changelog sagt:

    Der Service Layer prüft nun beim Start ob die bei den david Benutzern gespeicherte Windows SID mit deren wirklicher SID übereinstimmt. Im Fehlerfall wird ein Eintrag im david Ereignis Ordner mit Hinweisen zur Korrektur erstellt. Bei einer falschen SID kann es z.B. zu Problemen im smart client kommen. Weiterhin konnte es in einer Domäne zu einem Fehlverhalten kommen, wenn ein david User mit falscher SID dem richtigen Windows User zugewiesen werden sollte, in dem Fall konnte die SID weiterhin falsch bleiben.


    Die Nutzer wurden aber nie geändert.

    Was nun? Über den Drei-Punkte-Knopf alle noch einmal zuordnen?

    Hoffen, das dann nicht irgendwelche NTFS-ACL verfriemelt werden?

    Gerade eingespielt: "Unknown SID" bei allen Nutzern (in "DAVID/System/David/Events") und im Post-Eingang vom Admin (gesendet von David Service Layer).

    Hab die Einträge doppelt, da ich nach Rollout-Install Server neugestartet habe. Scheinen also bei jedem Start vom Service-Layer erzeugt zu werden.

    Client auf Client-PC zeigt jedoch Mails bei Normal-Nutzer an und bringt auch keine Fehlermeldungen.

    Senden und Empfangen geht auch.

    Das "Otherwise delete and, if necessary, recreate this david user." ermuntert ungemein.


    Soeben Service-Layer nochmal neugestartet. Wieder x mal "Unknown SID".


    Wer hatte hier vor Kurzem noch nach mehr Rollouts gefragt?

    Stand nicht in der Mail, als das mit den "Rollouts" los ging, so etwas wie "Lassen Sie sich aller 14 Tage mit/von neuen Features überraschen"?

    Wenn die Kommunikation mit dem Teil funktioniert (zeigen ja die Antworten auf die AT-Befehle), würde ich auch eher GSM-Netz-Probleme vermuten.

    Die bei SO genannten Gründe für Error 500 wurden sicher bereits geprüft?

    • No or weak network coverage - move modem somewhere with a better signal reception
    • Insufficient SIM card credit - charge SIM
    • International phone number required - send recipient's number to modem with country code