Beiträge von wlconsult

Um Deine 1und1-Accounts auf SSL umzustellen musst Du im DAVID Administrator folgendes einstellen:

Grabbing Server - POP3 Postfach - Eigenschaften - Zugangsparameter - Port: Hier 995 eintragen, Server-Adresse bleibt wie gehabt der pop.1und1.de, alles andere auch.

Zum Versand hängt es davon ab, ob Du Sende-Methoden für die einzelnen Postfächer definiert hast, oder über den POSTMAN direkt (als Smarthost) nur einen SMTP-Server benutzt. Bei Sendemethoden gilt im DAVID Administrator folgendes:

Postman - Datenbanken - Sende Methoden - Rechts im Fenster einen Rechtsklick auf die jeweilige Sendemethode und dann auf Eigenschaften - Port: Hier 465 eintragen, Server bleibt smtp.1und1.de, alle anderen Einstellungen bleiben ebenfalls wie gehabt.

Bei Versand über Smarthost gehst Du statt dessen direkt auf Postman, Rechtsklick und dann Konfiguration. Hier beim Provider auch direkt den Port 465 eintragen und kontrollieren, ob der o.a. SMTP-Server eingetragen ist.

Danach beide Dienste (Grabbing-Server und Postman) neu starten. Das sollte es gewesen sein und fortan läuft mit 1und1 alles über SSL.

Diese informationen gelten sinngemäß auch für GMX und WEB , weil diese ebenfalls zu United Internet Media gehören. Man muß nur die SMTP- und POP-Server entsprechend anpassen, die Ports sind dieselben.

Bei T-Online läuft es im Prinzip ebenso, allerdings benötigt man ein Email-Kennwort, welches vorher extra im Kundencenter eingerichtet werden muß. Als Benutzername wird dann statt der Konstruktion aus Anschlußkennung, T-Online- und Mitbenutzernummer der Email-Alias verwendet, als Passwort nicht das T-Online-Passwort, sondern das neue Email-Kennwort. Die Server heissen bei T-Online securesmtp.t-online.de und securepop.t-online.de. Die Ports sind 587 oder 25 für SMTP und 995 für POP.

Viele Grüsse aus München

Werner

Um Deine GMX-Accounts auf SSL umzustellen musst Du im DAVID Administrator folgendes einstellen:

Grabbing Server - POP3 Postfach - Eigenschaften - Zugangsparameter - Port: Hier 995 eintragen, Server-Adresse bleibt wie gehabt, alles andere auch.

Zum Versand hängt es davon ab, ob Du Sende-Methoden für die einzelnen Postfächer definiert hast, oder über den POSTMAN direkt (als Smarthost) nur einen SMTP-Server benutzt. Bei Sendemethoden gilt folgendes:

Postman - Datenbanken - Sende Methoden - Eigenschaften der Sende Methode - Port: Hier 465 eintragen, Server ist mail.gmx.net, alle anderen Einstellungen bleiben wie gehabt.

Bei Versand über Smarthost gehst Du statt dessen direkt auf Postman, Rechtsklick und dann Konfiguration. Hier beim Provider auch direkt den Port 465 eintragen und kontrollieren, ob der richtige SMTP eingetragen ist.

Danach beide Dienste (Grabbing-Server und Postman) neu starten. Das sollte es gewesen sein und fortan läuft mit GMX alles über SSL.
Viele Grüsse aus München

Werner

Genau aus diesem Grund gibt es seit Einführung von Sitecare bei uns hier keinen einzigen DAVID-Neukunden mehr. Früher konnte man noch auf Bugfixes und ein paar Service Packs hoffen, die grobe Fehler in der Software noch nachträglich beheben, bis die jährlich erscheinende neue Version von DAVID früher oder später ein kostenpflichtiges Update notwendig machte.

Jetzt ist mit jeglichem Support nach Ablauf von 30 Tagen nach Kauf Schluß, es sei denn, der Kunde schliesst Sitecare bereits beim Kauf mit ab. Damit wird das Produkt aber schon im ersten Jahr um ca. 50-60% teurer, als es der Listenpreis vorgaukelt. Und dieser Zusatzbetrag wird danach auch weiterhin jährlich fällig. Der Mitbewerb nimmt dafür normalerweise nicht mehr als 25%-30% pro Jahr, wobei Service und Updates im ersten Jahr nach Kauf i.d.R. kostenlos inbegriffen sind.

TOBIT verweigert dem Kunden damit jegliche Fehlerkorrektur (auch im Rahmen einer ggfs. anwendbaren gesetzlichen Gewährleistung) und stiehlt sich meines Erachtens hier einfach aus der Verantwortung. Wenn der Kunde das Produkt nicht bei TOBIT direkt kauft, sondern über uns als Händler, habe wir unsererseits im Rahmen der Gewährleistung den schwarzen Peter, falls die Version buggy ist - und darauf haben wir grundsätzlich keinen Bock.

Aber ich vergaß: DAVID hat ja von Haus aus keine Fehler ...

Viele Grüsse aus München

Werner

@Kamil: Dieser Bug wurde dadurch entschärft, dass Du beim Weiterleiten/Antworten derartiger Mails darauf hingewiesen wirst, dass im Text DAVID-Steuerbefehle stehen. Danach schaltet das Infocenter auf Textmodus um und nimmt die @@-Zeichen raus.

Ich habe noch ein bisschen rumgespielt und dabei entdeckt, dass man bei der o.a. Problematik durch Weglassen des "@domain...." in der Empfängeradresse auch interne Faxe verschicken kann. Wenn man im Infocenter also eine neue Email erstellt, als Empfänger nur "{12345}" eingibt und das dann abschickt, legt der Service-Layer wie gehabt einen neuen Benutzer an, macht dort sein Willkommensemail in den Eingang und dann noch die gerade erstellte Nachricht als Fax. Und ich bin sicher da geht noch mehr.

Vorstellbares Szenario: Ein User (und es kann wirklich ein DAVID-User mit so gut wie keinen Rechten sein) bekommt eine Joke-Mail, wo zig Empfänger im TO: stehen. Am Ende dieser Liste stehen dann noch 30 fiktive Empfänger nach dem Schema aus meinem Eingangspost. Das Infocenter zeigt Dir die Empfängerliste ja nicht komplett an, sondern spricht nur von "und ... weitere". Unser DAU drückt auf Antworten, weil er sich auch an dem Blödsinn beteiligen will und schon hat der Admin gut zu tun, weil es 30 neue Benutzer im System gibt. Einziger Trost: Der Admin weiß dann auch, wer es war und kann demjenigen einen Besuch abstatten. Aber er kann nichts tun, um so etwas zukünftig zu verhindern.

Übrigens: Wenn man zwischen den geschweiften Klammern die User-ID eines bekannten internen DAVID-Users schreibt, erhält dieser User die Nachricht direkt. Der Service-Layer legt in diesem Fall keinen neuen sinnlosen User an. Vielleicht ist das auch eine der oft dementierten Hintertüren, über die TOBIT z.B. seine Werbeemails verteilt. Ich erinnere nur an die Zeit, als vehement für FX12 geworben wurde und in meinem Kundenkreis mehrere Installationen waren, wo plötzlich alle User der jeweiligen Site eine Werbung für das Update auf FX12 in ihrem Eingang hatten, obwohl es keinen entsprechenden regulären Email-Eingang gegeben hat.

Werner

Hallo zusammen,

das Problem tritt derzeit offenbar nur beim Versand auf. Die Kunden erhalten von Ihren amerikanischen Mandanten wie geschildert Emails, bei denen im TO: eine oder mehrere hausinterne Empfänger genannt sind, im CC: aber neben evtl. anderen Empfängern auch die im Eingangspost geschilderte DMS-Empfängeradresse mit den geschweiften Klammern. Da nach RFC diese Emailadressen in Ordnung sind, werden sie von allen beteiligten Providern und Servern kommentarlos übermittelt und schlagen beim Empfänger im DAVID-Server auf. Dort kann man sie öffnen, drucken, löschen und sonst was damit machen - alles kein Problem. Wenn man aber auf eine dieser DMS-Adressen antwortet, schlägt der beschriebene Mechanismus zu und man hat auf Dateiebene einen kompletten neuen User ohne Namen im System.

Das bedeutet: Der Service-Layer entwickelt beim Versand einer Nachricht an eine Email-Adresse mit geschweiften Klammern (die vollständig den gültigen Standards entspricht) ein Eigenleben und das ist in meinen Augen kein Feature, sondern ein übler Bug, der TOBIT bereits seit 1 1/2 Jahren bekannt ist.

@Kato: Da schon Kingcopy von ähnlichen Erfahrungen in einem anderen Zusammenhang berichtet hat, liegt die Vermutung nahe, dass hier ein systematisches Problem vorliegt, das auch noch an ganz anderer Stelle zuschlagen kann. Wenn der Service-Layer von sich aus alleine durch eine passende Email-Adresse dazu veranlasst werden kann, ein komplettes Benutzer-Archive anzulegen, eine Willkommens-Email zu erzeugen und eine für den externen Versand bestimmte Nachricht in den Eingang dieses neuen Benutzers zu kopieren, dann ist in meinen Augen vom Prinzip her auch alles andere denkbar. TOBIT wird sich dazu aber überhaupt nicht äußern.

Vielleicht habe ich die nächsten Tage einmal Zeit, ein paar Experimente mit einem Testsystem zu machen.

Übrigens: Einer der Mandanten hat Lotus-Notes, der andere MS-Exchange. Wenn meine Kunden die Emails jeweils mit z.B. Outlook beantworten, funktioniert alles ohne jede Klage.

Werner

Ich habe gerade noch mit einem befreundeten TAR gesprochen: Der hat dieses Verhalten bei einem seiner Kunden schon im August 2011 mit fx.2011 festgestellt und über das Intercom an TOBIT gemeldet. TOBIT meinte damals dazu:

"Wir konnten diesen Effekt nachvollziehen, ..... Möglicherweise wird hierzu eine Änderung bzw. Anpassung schon in einem der nächsten Service Packs (Hotfixes) oder Releases enthalten sein."

Er meinte auch, dass TOBIT das offenbar nicht fixen will oder kann, weil es zentrale Funktionen des Service Layers betrifft und es gibt offenbar auch keinen Workaround dazu. Das was Kingcopy im Beitrag vorher beschrieben hat, würde sich dann mit dieser Aussage in so fern decken, als das es offenbar wirklich intern im Service-Layer Funktionen gibt, die bei Triggerung durch die geschweiften Klammern in Abhängigkeit vom Kontext entweder etwas Nützliches oder aber auch etwas total Unvorhergesehenes machen - und TOBIT weiß das schon seit Langem und macht die Augen zu.

Meine beiden Kunden wird das sicher freuen, wenn ich Ihnen davon berichte.

Ich wünsche Euch ein schönes langes Wochende!

Werner

Ja, die AUTOVALIDATION setze ich generell immer auf FALSE, denn sonst legt mir jeder Praktikant oder jede Teilzeitkraft, die eigentlich gar keinen Zugriff auf das Email-System haben soll, automatisch einen User an, wenn er aus Versehen das Infocenter auf seinem Rechner startet. Das o.a. Verhalten legt auch nur ein User-Archive auf Dateiebene an. Im DvAdmin selbst wird kein User erzeugt (wie bei AutoValidation=TRUE), es geht also auch keine User-Lizenz verloren.

Werner

Noch einer aus der Kategorie "Selber ausprobieren und staunen": 

Zwei Kunden von mir haben mit Mandanten in Amerika zu tun, die ein DMS einsetzen (offenbar vom selben Hersteller). Das DMS bekommt Kopien des ein- und ausgehenden Emailverkehrs über CC:-Empfängeradressen. Diese Adressen sehen so aus: „{xxxxxxxx}.blabla@domain.com“. Wenn einer der Mandanten eine Email an einen der beiden Kunden schreibt, steht im CC: immer eine der vorgenannten Adressen, wobei die Vorgangsnummer in den geschweiften Klammern steht. 

Drücken meine Kunden bei einer solchen Email auf antworten (und sie sollen auf „allen antworten“ gehen, weil der Mandant die Antwort automatisch in seinem DMS haben will), dann passiert beim Absenden der Antwort folgendes: 

Jeder „normale“ Empfänger erhält seine Kopie der Email. Diese werden wie gewohnt extern über POSTMAN verschickt. Die Email an das DMS jedoch erscheint sofort nach dem Abschicken im Ausgangsordner des Absenders als „interne“ Email. Extern wird sie nicht verschickt. Auch im Ausgangsprotokoll erscheint sie als interne Email. 

Wenn man dann im System nach der Nachricht sucht, stellt man fest, dass im Archive-System unter „Benutzer“ ein neues Archive ohne Namen angelegt wurde. Die Unter-Ordnerstruktur darin entspricht der eines normalen DAVID-Users. Im Eingang dieses Users existiert die bekannten Willkommensnachricht für neue User und die Email an das DMS. 

Eine Empfängeradresse mit geschweiften Klammern führt also beim Versand der Nachricht dazu, dass der Service-Layer auf Dateiebene einen neuen Benutzer anlegt und die Nachricht dort in dessen Eingang ablegt. Diesen User gibt es nicht als Benutzer im DvAdministrator. 

Ich habe das unter DAVID.fx 2011, FX12 und mit der aktuellsten david reproduzieren können. Das ist offenbar ein Riesenbock im Servicelayer. Das System macht sich an dieser Stelle selbständig, verändert reproduzierbar das Archivesystem und die Email an das DMS des Kunden wird nicht abgeschickt.

Das kann jeder von Euch ausprobieren, nehmt dazu einfach die oben angegebene Beispieladresse, schreibt eine Email an sie und schickt sie ab. Wer das zweimal macht, hat anschließend zwei neue namenlose Benutzer im Archivesystem, die er dann manuell über das Infocenter löschen kann. Sichert Euch vorher aber in jedem Fall die ARCHIVE.DIR des User-Verzeichnisses, denn die Datenbereinigung entfernt die Schrottuser nach Löschen der Archive nicht mehr aus der ARCHIVE.DIR, sondern kennzeichnet diese lediglich als gelöscht. 

Hat von Euch schon jemand ähnliche Erfahrungen gemacht? Gibt es da einen Workaround? 

Viele Grüsse 

Werner

Hallo zusammen,

dieser "Fehler" existiert in DAVID schon von Anfang an, genauso wie eine Menge anderer. Im Prinzip hat TOBIT an der Struktur des Dateibaums, an der Art der Dateiablage und allen damit verbundenen Fehlern und Problemen seit Jahren nichts mehr verändert. Es wird nur noch hier und dort ein bisschen was dazu "gepappt", und zwar überall dort, wo es ohne grosse Eingriffe möglich ist. Alles andere würde zuviel Aufwand und damit Kosten bedeuten.

Die letzte wirklich gute neue Version war aus meiner Sicht DAVID.fx bzw. eigentlich das gefixte FX.2011. Danach ist nichts mehr gekommen, was die horrenden Update- und Upgrade-Gebühren, geschweige denn die Sitecare rechtfertigen würde.

Einzig im Client tut sich hie und da noch was, aber dazu muß man ja den Server nicht antasten. Über die Nützlichkeit der neueren Funktionen des Client lässt sich trefflich streiten. Firmenkunden können davon jedenfalls so gut wie nichts gebrauchen, würden sich aber über einige dringende Bugfixes freuen (wie z.B. das Abstellen des o.a. Verhaltens).

Aus meiner Sicht reitet TOBIT das Pferd DAVID derzeit tot. Viele Firmenkunden haben das bereits durch die Hängepartie beim MAC-Client und beim Update auf FX12 erkannt. Viel Geld für nichts und wie immer eine Menge leerer Versprechungen. Mit der derzeitigen Sitecare-Politik stellt man sich noch weiter ins Abseits: Wo andere Firmen mit dem Kauf generell 12 Monate lang kostenlose Updates gewähren (und sogar eine bestimmte Zahl von Updates garantieren), steht bei TOBIT eine grosse Null, es sei denn, man überweist regelmässig und nicht zu knapp zusätzlich zum Kaufpreis Kohle nach Ahaus. Neukundengeschäft ist damit auf Dauer so gut wie nicht mehr möglich.

Bei unseren Kunden hier wird TOBIT im Laufe diesen Jahres ca. 200 Userlizenzen, verteilt auf 4 Installationen an den Mitbewerb verlieren, und diese kommen vermutlich auch nie wieder zu TOBIT zurück. Bei Händlerkollegen sieht es ähnlich aus. Wir verlieren dadurch keine Kunden, sondern installieren halt gängige Alternativen. Dann sind alle glücklich und TOBIT weiter auf dem absteigenden Ast. Ich bin gespannt, wann es den Laden zerlegt. Hier im Kollegenkreis laufen schon ein paar Wetten.

In diesem Sinne schöne Grüsse aus München!

Werner

Für die Bintec RT-Serie ist das derzeit "Release 9.1 Rev.2 Patch 4" vom 06.12.2012 (Zeitstempel der Datei), zusammen mit der Remote-CAPI 1.1.5 (Wincapi 1105) vom 28.06.2012. In der ZIP-Datei des Remote-CAPI sind zwei Versionen der CAPI für 32- und 64-bit Systeme. Die Downloads gibt's unter http://www.teldat.de/.

Viele Grüsse, Werner

Wir haben vergangene Woche einen RT1202 bei einem Kunden installiert, Firmware-Upgrade auf die neuste Version von den Herstellerseite inbegriffen. Die Faxübertragung dauert dort je nach Gegenstelle zwischen 31s und 57s für ein einseitiges Fax, egal ob versendet oder empfangen wird. Es hängt wohl sehr davon ab, ob auf der Gegenseite ein analoges Faxmodem "werkelt", oder ob z.B. eine rein digitale Gegenstelle vorhanden ist. Die Zeiten decken sich mit denen eines anderen Kundengerätes, das bereits seit letztem Jahr im Einsatz ist.

Viele Grüsse, Werner

Hi Klaus,

das ist doch schon mal gut, denn jetzt hast Du auf Verzeichnis-Ebene schon mal Zugriff. Als nächstes würde ich mich an Deiner Stelle auf dem fraglichen Client-Rechner im Infocenter unter "Netzwerk" - "DAVID-Server" einmal nicht nur mit dem Benutzernamen und Kennwort des fraglichen Users anmelden, sondern unter Benutzername auch die Domäne, in Deinem Fall den Namen Deines XP-Servers mit angeben, also: Benutzername z.B. SERVER\Username. Sollte das nicht den gewünschten Erfolg bringen, dann wähle als User den Namen eines Benutzers, der keine Probleme mit DAVID hat.

Wenn Du Glück hast, löst schon die zusätzliche Nennung der Domäne Dein Problem. Wenn es statt dessen mit dem alternativen User klappt, dann gibt es ein Problem mit dem neu definierten User (entweder auf dem Client oder dem Server). Wenn beides nicht klappt, dann stimmt in der Netzwerkumgebung zwischen dem neuen Client und dem Server etwas nicht.

Übrigens nur der Vollständigkeit halber: Die max. 10 Netzwerkverbindungen betreffen nicht die Anzahl der Benutzer/User, sondern die Anzahl der Rechner, von denen aus gleichzeitig auf den Server zugegriffen wird. Ein User mit zwei Rechnern oder zwei Logins zählt bei den Verbindungen doppelt. Wenn Du einen Netzwerkscanner hast, der die Scans per SMB auf Deinen Server transportiert, dann ist das auch eine Verbindung und die gilt nicht nur für den Moment des Scannens, sondern i.d.R. für mehrere Stunden (Nur damit wir nicht aneinander vorbei reden).

Viel Glück!

Werner

Wieviele Client-Computer (nicht nur DAVID-Clients, sondern generell) greifen derzeit per SMB auf die Verzeichnisse Deines XP-Servers zu? Bei Windows XP ist die max. Anzahl gleichzeitiger SMB-Connections auf 10 begrenzt. Du kannst diese Zahl verifizieren, indem Du an Deinem Server am Command-Prompt "NET CONFIG SERVER" eingibst. Unter "Max. angemeldete Benutzer" kannst Du sehen, wieviele Clients Dein Server unterstützt. Solltest Du das Limit überschritten haben, dann kann Dein DAVID-Client zwar mit dem Server reden, er kann aber nicht mehr per SMB auf das DAVID-Verzeichnis zugreifen und kann deshalb auch dort nichts sehen oder machen. Dieses Limit kannst Du m.W. nicht überrschreiten. Einziger Ausweg wäre ein richtiges Server-Betriebssystem.

Ansonsten läuft alles auf ein Berechtigungs-Problem des neuen Users auf Deinem Server hinaus.

Viele Grüsse

Werner

Hallo Feuerglut,

versuch mal Folgendes:

Gehe in den David-Administrator. Wenn Du die Email-Konten bei den Benutzern eingerichtet hast, dann zu dem jeweiligen Benutzer. Doppelklick auf den Benutzer, dann zu Email-Konten. Geh dann in die Eigenschaften des betreffenden Kontos und dort in das Register "Erweitert". Dort trägst Du bei "Verteilung" - "Zieladresse" folgendes ein: "*@deinedomäne.de". Wenn Deine User T-Online-Konten haben, dann also "*@t-online.de" (jeweils ohne die Anführungszeichen.

Wenn Deine Konten im Grabbing-Server eingetragen sind, dann statt dessen zum Grabbing-Server und dort zu den POP3-Konten. Dort wieder einen Doppelklick auf das jeweilige Konto und dann im Register "Zugangsparameter" wieder bei "Verteilung" - "Zieladresse" die o.a. Zeichenkette eintragen.

Danach sollte DAVID alle Email-Adressen im Header einer Nachricht (im To: und CC:-Feld) ignorieren, die nicht zu Deiner Domäne gehören und die Nachrichten nur jeweils einmal den betreffenden Usern zustellen.

Viele Grüsse

Werner

Prinzipiell schliesse ich mich dem vorherigen Post an.

Früher habe ich das mal zu Zeiten von DAVID 6.6 auf NOVELL Netware gemacht. Stichwort: Remote CAPI durch Auslagerung der TLDs auf einen anderen Server. In der Knowledgebase von TOBIT gibt's dazu die Artikel 107.471, 104.758 und 109.235. Ob das mit FX12 überhaupt noch funktioniert, kann ich nicht sagen. Theoretisch aber einen Versuch wert.

Eine wirklich funktionierende Lösung ist z.B. ein LanCOM-Router mit ISDN-Interface und LanCAPI. Alternative die sehr gut funktioniert: Bintec RT1202 (gibt's auch von TOBIT als "fxConnect4"). Da habe ich zwei Kundeninstallationen am Laufen, bei denen jeweils ein FX.2011 auf einem virtuellen W2k8 R2 Server unter Citrix Xenserver läuft. Der Bintec kostet ca. Euro 600 brutto. Wenn Du berücksichtigst, wieviele Stunden Du evtl. mit dem Remote CAPI o.ä. rumbasteln wirst, ist das aber relativ günstig und es funktioniert dauerhaft und gut.

Grüsse, Werner

Nicht anders schaut es beim Android-Client aus: Voller Fehler und seit Mai keine Veränderung mehr. Immerhin geht der wenigstens ohne grosse Probleme auch mit einer FX.2011 Installation. Meine Meinung hierzu wie auch zum MAC Client: Man kann daran sehen, dass TOBIT hier derzeit wohl weder Entwicklerkompetenz noch Entwicklerkapazität hat.

Aber die Geschäftsleitung von TOBIT gefällt sich ja auch ganz gut in der Position als Ahaus' grösster Gastronomiebetrieb, wie sie ja in einer Mitteilung an alle Partner lautstark verkündet hat. Vielleicht liegt hier ja die eigentliche Zukunft von TOBIT?

Apropos Facebook: Im Tobit-Partner-Network hat sich unsere Position beim Kundenbstand seit ca. 6 Monaten nur um einen Punkt verändert. Ich schliesse daraus, daß das Neukundengeschäft bei DAVID derzeit so gut wie tot ist und bestenfalls dringend notwendige Updates auf FX12 oder dringend benötigte Zusatzlizenzen verkauft werden können. Und Chanys wird wohl in Stückzahlen gesehen auch nicht so der grosse Bringer sein, denn sonst würden sich dessen Verkaufszahlen ja auch in irgendeiner Form in der Kundenstatistik niederschlagen.

Über "Das Maß aller Dinge!" kann man jedenfalls derzeit nur den Kopf schütteln.

Werner

Hallo Thomas,

damit kennst Du meines Wissens bereits alle Möglichkeiten, die es in DAVID für den Export von Adressen gibt: Entweder per "Datei"-"Dateiexport" als CSV-Datei oder per Drag & Drop auf das Desktop oder in ein Verzeichnis. Damit erhälts Du dann VCF-Dateien. Möglicherweise könnte man über ein Script noch etwas mehr erreichen, aber wer will/kann sich da schon einarbeiten.

Das Ergebnis Deiner Bemühungen musst Du dann noch manuell auf Doubletten untersuchen, denn eine zentrale Datenbank, wo Adressen nur einmal gespeichert werden und Gruppen über z.B. Verweise gebildet werden, gibt es in DAVID ja nicht. Vermutlich hast Du also nach dem Export (wie in jeder anderen DAVID-Installation auch) viele Adressen, die doppelt und dreifach (mit unterschiedlicher Aktualität und Vollständigkeit) in den verschiedenen Adress-Archives abgespeichert waren.

Viele Grüsse, Werner

PS: Im SQL-Server speichert DAVID ausser der Verschlagwortung der Nachrichten (für die Volltextsuche) gar nichts - Leider!

Hallo,

die aktuelle Android-APP für FX12 läuft einwandfrei in Verbindung mit dem FX.2011 Server. Es kommt bei der ersten Verbindungsaufnahme der Hinweis, dass evtl. nicht alle Features unterstützt werden, aber dann läuft sie einfach. Hoffentlich ist das in den Augen von TOBIT ein Feature und kein Bug, sonst ist es damit beim nächsten Release der APP wahrscheinlich vorbei. Nur dass das bei Android nicht so das Problem ist wie bei den iTouch-Geräten .

In meinen Augen auch ein klarer Hinweis darauf, dass man bei TOBIT die Kompatibilität gar nicht wünscht, sondern die User durch "sanften" Zwang zum Update (und damit zum Zahlen) überreden möchte. Mit Innovation und Weiterentwicklung hat das an dieser Stelle nichts zu tun.

Viele Grüsse

Werner

Hallo,

hat sich der Username des betroffenene Nutzers geändert? Bei meinen fx2011- Installationen ist es so, dass wenn im Usernamen z.B. ein abgekürzter Dr.-Titel steht (also "Server" - "Benutzer" - "Mustermann, Dr. Max") der Webclient und der Zugriff über die iPhone-APP nicht mehr funktionieren. Schuld ist der Punkt, der beim Browserzugriff (und auch die iTouch-Clients arbeiten so) alles was danach kommt als Extension ansieht. Die so abgefragte URL gibt es auf dem DAVID-Server in der Webbox nicht. Falls das bei Dir der Fall ist, dann nimm den Punkt oder am besten gleich jedes andere Sonderzeichen aus dem Namen raus und probiers nach Anpassen der Zugriffsdaten auf dem iPhone/iPad noch mal - es sollte wieder gehen. Das Komma in o.a. Beispiel stellt übrigens kein Poblem dar.

CARDDAV und CALDAV, sowie der Android-Client brauchen den Namen des Users aus dem Archive-System nicht, die fragen nur nach Login-Namen und Kennwort (also den reinen Remote-Access-Daten). Bei denen gibt es das Problem grundsätzlich nicht. Mit FX12 habe ich das noch nicht probiert, was daran liegt, dass meine Kunden FX12 gelinde gesagt "meiden".

Viele Grüße
Werner