ContactEditor für den Contactviewer

Tja, das Problem mit dem 'case sensitive' zu finden (Windows ist es ja eigentlich egal), war jetzt eher Glücksache, auf einem UNIX-System stößt man da schon eher auf solche Probleme. :smt004

Aber die Idee mit dem Editieren der Kontakte gefällt mir, zumal es ja aktuell keine bequeme Alternative gibt. Wobei ich mal die Frage im Raum stehen lasse, bei einer Beta eher den Testzyklus zu erweitern und nicht gleich an die Kohle zu denken!

Da es bisher wenig Feedback gibt und ich mich schon hier so einbringe, kommen gleich noch ein paar Vorschläge, die IMO den Mehrwert des Tools wesentlich erhöhen bzw. es eigentlich erst abrunden würden:

- Sortierreihenfolge ändert sich nach dem <ändern> drücken, Header bleibt aber markiert. Ein Beibehalten wäre aber wünschenswert, auch beim Zurückschreiben in die DB.

- Import aus *.csv oder auch *.xls für diejenigen, die aktuell zwar Outlook besitzen (wie ich bspw.), aber leider nicht syncen können. Vlt. am besten mittels einer Vorlage (Template)?

- (Teil-)Inhalt der Favoriten aus Destinations.db importieren/einlesen per Menuepunkt (Hintergrund ist anscheinend dort ein Problem ab einer Anzahl von ~30 Einträgen)
Vlt. sollte in der Testversion hier jeweils nur der 1. Satz importiert werden können? :))

- Option "aufteilen für CV..." wäre IMO besser mit "Änderungen in DB zurückspeichern..." bezeichnet. Selbst ich als PC-Power-User hatte kurz überlegen müssen, was damit gemeint war.

Ansonsten, wie gesagt, ein schönes Tool :top , was aber aktuell noch nicht so seinen Preis wert ist (sorry, meine persönliche Meinung, bin halt ehrlich). Aber mit den weiteren Ergänzungen, die den Nutzen erhöhen, wäre ich dabei, versprochen!

Will nicht stören, diese Diskussion schläft ja nun auch schon seit Januar.
Aber mir fällt ein, wie ich mich nach meinem Computerabsturz um die Nutzung der gerettete .db bemühte..
Die über den ofiziellen Weg bei GoPal3 mit CV3.0 aus Outlook (oder OE ? Ich weiß es nicht mehr genau) erhaltene .db war viel größer als für eine spätere Nutzung und Bearbeitung erforderlich. Offenbar war dies eine Notwendigkeit für das wiederholte Syncen mit O(E). Da ich des Syncen also verlustig ging, habe ich mich seither um native Nutzung einer reinen und bearbeiteten Datei bemüht, was mich über die verschiedenen SQL3-tools, von denen einige ja keine Umlaute korrekt anzeigen oder generieren wollten, schließlich zu OpenOffice führte. Natürlich ist dort das Schreiben ebenfalls fummelig, wegen der korrespondierenden Id in den einzelnen Tabellen. Vorteil: In der Ansicht der Tabellen und Verbundtabellen(DB-Ansicht) kann man in allen Spalten zwischensortieren, um sich die Handarbeit einfach zu gestelten. Natürlich ist Dein Programm, sofern es ohne Einschränkung und sicher funktioniert, besser.

Lange Rede, kurzer Sinn: Die korrekt exportierte contacts.db ist viel größer als für den Navigator erforderlich und man kann die Satz-Id auch reorganisieren, z.B. um Karteileichen auch mit Id zu löschen, sofern man dies haben möchte, die Reihenfolge wieder kontinuierlich per Hand gestalten.

Hier ist's ruhig, weil's hier zuletzt weiterging: http://www.gopal-navigator.de/viewtopic.php?p=50255#50255

Größe der DB: auch eine *.mdb wächst im Laufe der Zeit und kann unter Access komprimiert werden. Aber mag sein, dass das Syncen mit dafür verantwortlich ist. Ich kann's mangels der V3 nicht mehr testen.

Eine wesentliche Beeinträchtigung beim Einlesen der DB habe ich aber nicht feststellen können. Hier war's auch mal ein Thema, bei den Favs: http://www.gopal-navigator.de/viewtopic.php?p=49194#49194

Habe Dein Prog. soeben getestet. Leider sind die Geschäftsadressen nicht sichtbar, obwohl sie im Navi gesehen werden. Also noch kleine Bugs?

Zitat von quotsi

Habe Dein Prog. soeben getestet. Leider sind die Geschäftsadressen nicht sichtbar, obwohl sie im Navi gesehen werden. Also noch kleine Bugs?

Du bist auch meinem Link gefolgt und testest die V2.x?

Zitat

Natürlich ist dort das Schreiben ebenfalls fummelig, wegen der korrespondierenden Id in den einzelnen Tabellen. Vorteil: In der Ansicht der Tabellen und Verbundtabellen(DB-Ansicht) kann man in allen Spalten zwischensortieren, um sich die Handarbeit einfach zu gestelten. Natürlich ist Dein Programm, sofern es ohne Einschränkung und sicher funktioniert, besser.

Nein, dort kann man nicht für die Ansicht in den Spalten Daten sortieren. Ich wüßte nicht, wie Du da schnell einen Datensatz finden kannst. Darin ist OOo meilenweit besser.
Dennoch bleibt unbesehen Dein Konzept/Programm viel besser, sofern es ganz fehlerfrei läuft.
Ich habe aber schon berichtet, daß bei mir die Geschäftsadressen in Deinem Prog. nicht angezeigt werden.
Zweitens sehe ich in einigen Datensätzen (vermutlich aus alten Daten aus OE, die nicht editiert wurden, noch komische Feld-Endekennzeichen, nicht bei allen Datensätzen und allen Feldern.

Zitat

die contacts.db vom editor erstellt, ist genau das, was der editor braucht. was soll da überflüssig sein??

Wir haben uns falsch verstanden. Mein Beitrag zu eurer Runde war wegen der Ursache, warum jemand nicht importieren konnte, daß die aus OutlookExpreß oder OE (ich weiß nicht mehr genau welche Quelle ich selbst nahm), größer war, als notwendig, wie ich durch Extraktion in anderen Tools schnell nachweisen konnte. Ferner glaube ich, daß dieser Datenmüll, der an sich für den Navi und sein CV-Programm unnotwendig ist, nur der Rückwärtskompatibilität zu OE geschuldet war. Aber das muß nicht einmal stimmen.
Jedenfalls ist meine Datenbank jetzt, nach vielen Bearbeitungen mit SQLiteSpy, sqliteadmin, SQLite Database Browser oder zuletzt OOo-Base immer kleiner geblieben als jemals aus OE.

Zitat

sqlite nutzt selbstständig entstandene "lücken" innerhalb einer db (siehe doku sqlite) - vacuum ist also nur etwas fürs user auge
die ID ist für den user vollkommen nebensächlich - steuert lediglich zusammenhängende adressen und telefonnummern im viewer - warum die nun unbedingt in reihenfolge sein müssen wie von einigen gewünscht kann ich nicht nachvollziehen...würde die nicht im editor angezeigt wüssten die meisten wohl gar nichts von deren existenz...
kann aber auch im editor reorganisiert werden mittels ex/import und datenbank löschen...

Fein und bei solchem Komfort nicht mehr notwendig, da stimme ich Dir zu.
Bei händischer Datenpflege hingegen macht sich eine Bereinigung sicher bei der Fehlersuche nach Inkonsistenzen nützlich.

Die Darstellung der Geschäftsadressen meiner contacts.db fehlt aber nur in Deinem Programm, nicht im Medion selbst!

Ich benötige keine 4 Programme, um die Datenbank zu editieren, nur hatte ich im Verlauf der Zeit neben- und kurz nebeneinander dieselbe Datenbank in den 4 Programmen zu editieren versucht und editiert. Das eine Prog. konnte keine Umlaute, das andere konnte keine Datensätze anfügen, sondern nur vorhandene editieren, das dritte erst konnte Tabellen spaltenortiert darstellen.
Als ich genervt aufhören wollte, fand ich heraus, wie das bequem in OO laufen kann. So bin ich bei OO geblieben.

Aber ich wiederhole mich, auch hier muß ich jede Tabelle einzeln bearbeiten, in Deinem Programm hingegen wird der Zusammenhang besser dargestellt und für Ungeübte ganz sicher erleichtert.
(Nur für mich gilt, daß ich nicht eher umsteige, bis für mich der Fehler in der Datenbank (?), der innerhalb Deines Programms auftritt, erkannt ist. Natürlich kann dies an meiner DB liegen, aber dazu muß ich erst einmal wissen, wo)

UTF8-Format ? Wird dies jetzt für GoPal5 besonders gefordert? Vielleicht ist das auch die Ursache, warum Umlaute in Namen (komischerweise nur in Namen, nicht in Straßennamen oder Städten) in der DB, die noch im CV3.0 unter GP5 korrekt erscheinen, in der Navigation von GoPal 5 nicht korrekt angezeigt werden? Wer weiß das?

Müßte ich im Falle der Nutzung Deiner Software alle die komischen Endekennzeichen einmalig tilgen? Das könnte man ja verschmerzen.

Aber wieso werden diese Zeichen nicht im Medion angezeigt? Dem scheinen diese Unterschiede in den Endekennzeichen schnuppe zu sein.

Ich behaupte mal, daß meine Datenbank konsistent ist, so wie sie sich im OO und im Medion anzeigt. Feinheiten im Zeichensatz vielleicht können fehlerhaft sein.
Daß Geschäftsadressen nicht angezeigt werden, ist doch wohl anderen Dingen geschuldet (CategoryID ?).

Mit freundlichem Gruß

Zitat von Contacteditor

korrekte darstellung im viewer? sprich 1 name 2 adressen ?

Kurzer Vorspann, damit wir nicht aneinander vorbeireden:
Ich nutze jetzt GoPal5.0, habe den CV3.0 in dieser Umgebung drin und werde solange meine Adressen dort pflegen, bis ich kostengünstig mal irgendwann dann doch noch ein GP5-Adressbuch erhalten kann. Das wird ganz sicher nicht vor dem Sommer angeboten und wird wahrscheinlich noch zu teuer für mein Budget eines einfachen Bürgers sein. Oder Dein Prog. sofern es für mich fehlerfrei läuft.

Outlook neu kostet was. Nach einem Absturz meiner Festplatte (was zeitlich zu erwarten war, nur nicht für mich) ging der Datenbestand flöten. Da lernte ich kennen, welche Daten man wiederherstellen kann und welche nicht. Outlook gehört zur letzten Gruppe.

Mein Gott, wie oft muß ich mich wiederholen? Dein Programmansatz ist unbestritten gut, ich würde soagr die 7,50 akzeptieren. Nur muß es bei mir (!) korrekt laufen.

UTF8-Format ?
Ja, ich habe es nachgesehen. Mein OO ist auf UTF8 für diese DB eingestellt. Es war also alles korrekt. Mein Text hierzu war ein Irrtum. :smt022

In OO (und im CV 3.0 unter GoPal5.0) werden ja keine solche Zeichen angezeigt, das ist es ja grade...

ZU Geschäftsadressen und CategoryID ?
[quote]categoryID möglich - da ja auch nach sync per outlook im original die falschen icons für privat/geschäft angesprochen werden.

Alles anzeigen

.db über MS ActiveSync oder direkt über CardReader auf die SD zu schieben bewirkt bei mir keine Unterschiede, also prüfe ich dies nicht mehr.
CatId ist da schon eher der Knackpunkt. Hast Du im Kopf, welche CatId in Deinem Programm beim Daten-Neuschreiben die Geschäftsadressen erhalten? Laut Tabelle Categories gibts ja nur 3, die 3 für Business, was ich als Geschäft für Adresse und Telefon interpretiere und auch so vom CV3.0 akzeptiert wird.

Nun die Überraschung
Man kann sogar jeder Person in Adresse die Catid 2 (=mobil =Urlaubsadresse (?) oder ostdeutsch Datsche) zuordnen und diese Angabe (wurde in OO eingetragen) wird im CV V3.0 unter GoPal5.0 korrekt interpretiert und führt im Navi zum Ziel.

Also mußt Du Dein Programm um diese Möglichkeit noch erweitern :zzz

Zitat

hast dir die contacts.db aber nicht wirklich genau angesehen....sonst würde die grosse überraschung schnell verblassen
CatID bei adressen: 1=privat / 2=geschäftlich
CatID bei telefon: 3 =mobil

so ist die zuordnung offiziell von gopal und auch die zuordnung der icons erfolgt nach der vorgabe.

Ich habe die Struktur der Datei NIEMALS angefaßt.
In der Ansicht der Tabelle categories steht in englisch, was mir nie in den Sinn käme, geben alle genannten Programmen wieder:
1 Home 2 Mobile 3 Business.

Jetzt könntest Du auf die Idee kommen, daß diese nicht mit meinen Bildern im Gerät übereinstimmen. Nein, ich kann Dich beruhigen. Ich habe den verschieden Positionen eindeutige und verschiedene Inhalte eingetragen und erhalte
bei den Adressen in folgender Reihenfolge angezeigt:
Home=1 ein Wegweiser angezeigt
Business=3 ein Wegweiser mit (Geschäfts?)Haus (was zugegebenermaßen verwirren könnte)
Mobile=2 ein Wegweiser mit Aktentasche.

Die Bilder für Phonenumbers sind in folgender Reihenfolge:
Home=1 Telefonhörer mit Bildschirm o.dgl.
Business=3 Telefonhörer mit Haus
Mobile=2 Telefonhörer mit Aktentasche

Jetzt könnte noch der Einwand kommen es handele sich um verschiedene Geräteausgaben. DAS ist möglich. Mein Profil aber kannst Du ersehen.