Adressübertragung David-Server/Iphone & Probleme mit vielen Adressen

PKD

Hallo,

ich habe ein ziemliches Problem mit David in Bezug auf die Iphone-App, einen anscheinend ratlosen/unwilligen Support bei Tobit und einen ziemlich genervten Chef. Jetzt frage ich einfach mal ob evtl. jemand von euch eine Lösung hat:

Wir haben einen Server, Version David.fx 11.00a - 2378. Auf einem Iphone 5 ist der David-Client 1.332 installiert (Die letzte Version die mit unserem Server funktioniert).

Der Benutzer des Iphone hat keine Kontakte auf dem Iphone, alle Kontakte (ca. 750) sollen von David kommen. Deshalb habe ich zuerst die Grundsynchronisation gestartet. Dies funktioniert auch: Es werden die ca. 750 Adressen auf das Iphone übertragen.

Der Benutzer möchte aber den gesamten Adressbestand unserer Firma auf seinem Iphone haben (ca. 5.500). Deshalb habe ich seine 750 persönlichen Adressen gelöscht/verschoben und habe die Gesamtadressen in seine persönlichen Adressen kopiert und wieder die Grundsynchronisation gestartet. Dies wiederum funktioniert nicht! Es kommt ziemlich schnell "Synchronisation beendet" obwohl überhaupt keine Adressen übertragen worden sind!

Tobit hat mir bereits geantwortet daß 5.500 Adressen überhaupt kein Problem sei, es gibt keine Beschränkung bei den Adressen, auch mit 5.500 läuft die Synchronisation; haben mich aber im gleichen Atemzug auf eine neue Version von David verwiesen die bessere Unterstützung für das Iphone bringt. Jetzt ist es für mich natürlich schwierig, meinem Chef zu erklären daß wir eine neue Version kaufen sollten obwohl ja angeblich nicht mal die alte Version ein Problem hat!

Außerdem haben wir das Problem daß die Suchgeschwindigkeit innerhalb der 5.500 Adressen auf den PC-Clients (ca. 10 Clients) teilweise sehr langsam ist. Teilweise dauert es zwischen 40-50 Sekunden bis das Ergebnis kommt. Gibt es eine Möglichkeit/Einstellung dies zu beschleunigen? Nach der ersten Suche ist die weitere Suchgeschwindigkeit hervorragend aber z.B. eine Stunde später ohne Suche bricht die Geschwindigkeit bereits wieder ein! Getestet: 1. Mal: 47 sec., 2. Mal: 36 sec. Außerdem ist die CPU-Belastung auf dem Server jedes Mal ziemlich hoch.

Kommt die mangelnde Geschwindigkeit evtl. davon daß jede Adresse jeweils 2 Dateien sind und deshalb im Adress-Verzeichnis über 10.000 Dateien sind?

Hat hier jemand Erfahrungen mit so großen Adressbeständen im Allgemeinem und besonders im Zusammenspiel mit einem Iphone?

Hoffe auf Antworten auch wenn ich weiß daß das sehr spezielle und wahrscheinlich eher ungewöhnliche Fragen sind. Trotzdem Danke schon im Voraus!

Arno

In einem ähnlichen Fall war das Rootverzeichnis der David-Installation beschädigt. Auch dabei endete der Webbrowser nach kurzer Zeit.
Erste mögliche Maßnahme: Arcutil "Verzeichnisse" ausführen für das Rootverzeichnis und für das betroffenen Adressverzeichnis.

Arno

Es kann auch helfen, das Verzeichnis "David\Archive\SYSTEM\DAVID\Access" umzubenennen und den Inhalt aus einer frischen Installation zu ersetzen. In dem Fall aber bitte die Servernamen in der Kopfdateien mit Arcutil passend ändern.

Racer1000

Hi

DAs gliche Problem mit dem Iphone hatten wir auch. Solche Datenmengen auf das Iphone zu Syncronisieren funktioniert nicht wirklich. Wir habe dafür die CALDAV Schnittstelle konfiguriert. Und keine Adressen mehr Lokal abgelegt.

Was die Geschwindigkeit beim Adressen suchen im Client angeht hilft nur eines wirklich. Einen Server mit sauschenllen HDD und einem sehr guten Controller. Klar sagt Tobit das es geht sovile Adressen in einem Archiv. Aber wenn es um schnelligkeit geht ist der David nicht das gelbe vom Ei.

gruß RAcer

Arno

CardDAV und 5500 Adressen? Da werde ich etwas vorsichtig. Denn wenn der User mehr als ein Smartphone nutzt (Multisim, ein Smartphone im Auto und eins im Jackett) dann ist rasch das vom Provider für's Smartphone vorgegebene Volumen überschritten. -

Man müsste sich mal die Mühe machen, eine frisch aufgesetzte aktuelle David-Installation mit 5000 Adressen zu füllen und diese mit einem Smartphone zu synchronisieren. Momentan habe ich nicht genug Zeit dafür. Aber vielleicht probiere ich es noch vor Mitte Juni aus. Ich bin optimistisch und gehe davon aus, dass es funktionieren wird.

Was aber nach meiner bisherigen Erfahrung problematisch ist: David-Synchronisation und CardDAV parallel auf dem gleichen Gerät zu nutzen. Bis jetzt empfehle ich meinen Kunden ergo entweder zu synchronisieren oder CardDAV zu nutzen. Verbesserungsvorschläge willkommen!

Arno

Oberhalb der angezeigten Adressliste gibt es ein Eingabefeld, in das ein Suchbegriff eingegeben werden kann. Meist ist das Name, Vorname, Ort oder Postleitzahl. Sofort beim Eintippen verringert sich mit jedem Buchstaben die angezeigte Trefferliste. Diese Suche ist Filesystem-basierend und daher unerreicht schnell. Auch bei einem 3500 Adressen enthaltenden Verzeichnis ist normalerweise keine Verzögerung wahrnehmbar. Vielleicht ist dem genervten Chef schon etwas geholfen, wenn er nicht immer die Volltext- und Internetsuche benutzt.

Anders sieht es aus, wenn mittels der SQL-Datenbank gesucht wird. Das wird nötig, um zum Beispiel statt nach einem Namen nach einem Geburtstag oder einem KFZ-Kennzeichen zu suchen. Die zugehörigen Spalten der Adressliste sind im David-Client nicht auswählbar. Aber die David SQL-Datenbank nimmt die Inhalte der zugehörigen Variablen per Indizierung auf. Zur Nutzung der SQL-Suche mit der Maus auf einen Eintrag im Navigatorbaum klicken und mit der rechten Maustaste "Suchen" wählen.

Diese Suche dauert viel länger, weil die Antwortgeschwindigkeit einer üppig mit Daten gefüllten SQL-Datenbank mitunter unbefriedigend ist. Die Antwortgeschwindigkeit kann sich enorm verzögern bei hoher Serverauslastung (läuft gerade eine Datensicherung?) oder während die Indizierung neu aufgebaut wird. Die Indizierung erfolgt in regelmäßigen Abständen automatisch. Wenn der Systembetreuer die Taktrate der Indizierung zu stark verringert, dann ist die SQL-Datenbank fast nur noch mit sich selbst beschäftigt [Taktrate der Indizierung reduzieren, Vorgehensweise bitte via InterCom erfragen]. Als weitere Performancebremse kommt die Zahl gleichzeitiger Suchvorgänge in Betracht. Je mehr User gleichzeitig in der SQL-Datenbank suchen und je mehr weitere Anwendungen den Server belasten, umso mehr steigt die CPU-Last . Und bei hoher CPU-Auslastung werden die Ergebnisse langsamer geliefert. So kommt es zu den von PKD beobachteten Unterschieden in der Suchgeschwindigkeit.
Bessere Antwortzeiten der Suchfunktion lassen sich Hardwareseitig durch Einbau einer zweiten Server-CPU, mehr Arbeitsspeicher und schnellere Netzwerkkonponenten erreichen. Zudem sollten die SQL-Pfade beim Server-Virenscanner aus dem ständigen Scanbereich ausgeklammert werden.

Jetzt mitmachen!