Beiträge von Andreas Simon

    DerDAVID Client auf einem Windows 2012 (kein R2) Terminalserver startet
    nach einer Neuinstallation der DAVID Clients bei keinem Benutzer mehr.
    Fehlermeldung: "Der Prozedureinstiegspunkt "TOBITCLT_CreateCanvas" wurde
    in der DLL "C:\Program[...]\DVWIN32.EXE" nicht gefunden.
    Bereits erfolglos getestet wurden die folgenden Maßhanhmen:
    DAVID
    Client deinstalliert, Tobit Registry Einträge bei Benutzer und HKLM
    entfernt, DLLs bereinigt, Tobit Bereich in C:\Programdata gelöscht,
    Tobit DLLs aus dem Windows und System32 Verzeichnis entfernt und Client
    neu installiert.
    Client Installation probeweise von einem anderen
    Server im gleichen Unternehmen installiert, um auszuschließen, dass das
    Client-Verzeichnis auf dem DAVID Server beschädigt ist.
    Server probeweise auf das aktuelle Rollout hochgezgen und Client aus der neuen Version neu installiert.


    Hat alles nichts geholfen. Hat jemand zufällig eine Idee, wo die Ursache liegen könnte?

    Ohne die API zu bemühen, wird das mit Bordmitteln nichts werden. Bist Du sicher, dass Du die Daten in unübersichtlichen EML Dateistrukturen ablegen willst?
    Sollen die Daten später wieder im DAVID lesbar sein, käme ein Strongbox-Sicherung einzelner Ordner oder ganzer Strukturen in Frage. Ist nur die Archivierung gefragt und kein Import in andere Programme erforderlich, ließe sich DvArchiv von Syntax einsetzen (bringt einen eigenen Browser für die Archive mit). Auch in Frage käme, per IMAP von einem Outlook aus auf die zu archivierenden Daten im DAVID zuzugreifen und diese dann als PST Datei abzulegen.

    Hallo Jens,


    da passiert so Einiges. Mit fällt da zum Beispiel die ferngesteuerte Deaktivierung der SLS ein, die aus unerfindlichen Gründen immer wieder mal ausgelöst wird. Weiter wären da die Echtheitsbestätigungen und die Aktivierungen der System Services, bei denen ich nicht mal einen Überblick habe, welche Rechte für welche Aktivierung benötigt werden, die ja teilweise clientseitig ausgelöst werden können. Klar kann ich da einen Packet Sniffer drauf ansetzen - die Frage war ja auch, ob das schon mal jemand gemacht hat.


    Grüße


    Andreas

    Mit geht seit geraumer Zeit die Auskunftsfreuigkeit von DAVID in Richtung Ahaus mächtig auf den Zeiger. Die Jungs sind schlimmer als Apple und Facebook zusammen, aktivieren und deaktivieren aus der Ferne System Services, wie es ihnen beliebt und verstecken an allen Ecken und Enden Schalter und Warnhinweise, die darauf abzielen, dass kostenpflichtige Dienste beworben und absichtlich oder unabsichtlich aktiviert werden. Neuester Gag aus dieser Ecke ist das nervige "David.Care" Symbol im Client.


    Hat sich schon mal jemand die Arbeit gemacht, die TCP Kommunikation mit Ahaus auszuwerten? Ich hätte Interesse an einem Werkzeug, mit dem sich die Kommunikation mit Ahaus selektiv oder generell unterdrücken lässt. Eine Serverliste täte es auch - dann könnte man die Plauderei per hosts File unterbinden.


    Grüße


    Andreas Simon

    Hallo zusammen,


    Faxsendungen über das API Verzeichnis funktionieren nicht mehr. Beim Erstellen eines Sendeauftrags über den Druckertreiber bleiben die erzeugten Dateien (Faxseite und .JOB Datei) im Api-Verzeichnis liegen und werden vom Servicelayer nicht angefasst. Der Versand über den David Client funktioniert sowohl für Faxe als auch für E-Mails. API- und Filescanservice wurden bereits neu erzeugt, die Berechtigungen für das API Verzeichnis sind korrekt, der Servicelayer wird mit dem Domain Admin Account ausgeführt.


    Hat jemand eine Idee, wo ich noch suchen könnte?


    Herzlichen Dank und Grüße


    Andreas

    ... durch x-te Neuinstallation des SQL Servers. Ich habe in diesem Fall wieder die Version aus dem letzten DVD Image von Tobit Software verwendet. Leider hatte ich vor Plätten des SQL keine Volltextabfrage mehr getestet. Denn genau dort vermute ich auch den Verursacher. Allerdings hatte ich ja (unvollständige) Suchergebnisse. Also müsste der Volltextindex zumindest teilweise gefüllt gewesen sein.


    Grüße


    Andreas

    Hallo nochmal,


    ich habe das Problem noch mal Schritt für Schritt nachvollzogen: Das SQL Suchergebnis wird beim jeweiligen Benutzer in den Ordner System\Suchergebnisse in die archive.dat geschrieben (herzlichen Dank nach Ahaus für diese Information). Im vorliegenden Fall fehlen dann die benötigten Informationen bereits in der archive.dat. In der SQL Datenbank ist der Datensatz vollständig (z.B. beim Testdatensatz das Feld "Betreff" (=srSubject), in der archive.dat fehlt unter anderem diese Information. Die Daten müssen also auf dem Weg von der Datenbank in die Archive verloren gehen. Letztlich fehlt dann wohl auch die Angabe des Nachrichtentyps. Der Client versucht beim Doppelklick auf ein Suchergebnis nämlich, E-Mails mit dem Image Editor zu öffnen, was dann zur initial beschriebenen Fehlermeldung führt. Hat jemand mit diesen weitgehenden Informationen eine neue Idee?


    Herzliche Grüße


    Andreas Simon

    Hallo Jens,


    danke für die Antwort. Wenn die Ursache eine defekte Archivestruktur wäre, müsste sich der Fehler eigentlich auf die einzelnen Unterarchive unterschiedlich auswirken. Deswegen fehlt mir da ein wenig der Glaube.


    Da aus Ahaus keine technische Hilfe zu erwarten ist und ich nicht gedenke, den kompletten David Server neu aufzusetzen, nur um festzustellen, dass das auch nicht geholfen hat, bleibt wohl nur, auf die SQL Suche zu verzichten. Es sei denn, es findet sich jemand, der nähere technische Informationen bereitstellen kann - gerne auch gegen Bezahlung.


    Interessensfrage: Gibt es Themen, in denen die Tobit Software Supportmitarbeiter tief drin sind?


    Grüße


    Andreas Simon

    Hallo Jens,


    der Pfad in den Eigenschaften des angezeigten Suchergebnisses ist korrekt. Wie in meinem Posting geschrieben: Werfe ich exakt diesen Pfad dem Explorer vor die Füße, öffnet er mit auch die richtige Nachrichtendatei. Nur die Anzeige im Client ist murks. Den SQL Server habe ich mittlerweile mehrfach neu installiert, Datenbanken gelöscht, neu aufbauen lassen, etc. Das Problem tritt auch ausnahmslos in allen Archiven auf. An eine defekte Struktur mag ich da nicht glauben. Weißt Du zufällig, wie das Suchergebnis verwaltet wird? Erzeugt der Server irgendwelche Dateien, die dann der Client zur Anzeige verwendet?


    Solche Informationen, die überhaupt erst eine Fehlersuche ermöglichen würden, werden in Ahaus ja strenger gehütet, als das Coca Cola Rezept.


    Grüße


    Andreas

    Hallo,


    David.fx 2011 mit allen Servicepacks (außer dem heutigen):


    Die Datenbanksuche im David Client funktioniert nicht. Die Datenbank wurde ordnungsgemäß erstellt und wird auch gefüllt. Ein ODBC Zugriff auf die Datenbank ist möglich, die Datensätze sehen - soweit ich das beurteilen kann - korrekt aus.


    Wird nun per F3 eine Suche im Client ausgelöst, gibt der Client ein (an sich) korrektes Suchergebnis heraus (Anzahl der gefundenen Nachrichten und der angegebene Pfad zur Nachricht stimmen). Allerdings wird nur ein leerer Nachrichteneintrag angezeigt (Betreff: "Ohne Absenderkennung"). Ein Doppelklick auf den Eintrag produziert die Fehlermeldung "Die Datei \\server\arc(...).001\ konnte nicht geöffnet werden. Es bestehen keine Leserechte oder sie hat eine unbekannte Extension). Gibt man den angezeigten Pfad zur Nachrichtendatei manuell im "Ausführen" Dialog von Windows an, öffnet sich die richtige Nachricht.


    Der Fehler tritt unabhängig von den Rechten des angemeldeten Benutzers auf. Auch ein Domain Admin erhält die Fehlermeldung. Service Layer und Datenbankinstanz werden mit dem Domain Admin Account gestartet. Der Support in Ahaus hat (wie üblich) die Segel nach den immer gleichen Rückfragen gestrichen.


    Hat jemand eine zweckdienliche Idee, wie ich in der Ursachenforschung weiter vorgehen könnte?


    Grüße


    Andreas Simon