ContactEditor 2.0

    Ein 1. Test dieser Version ist schon mal sehr positiv! Meine vorliegenden Adressdaten werden nun nicht mehr gelöscht.


    Mein Hardcore-Test mit Outlook-Export (92 Spalten!) und Import in den CE macht aber einige manuelle Anpassungen notwendig (u.a. Spalten löschen und umbenennen), das teste ich im Ganzen erst später.

    Zitat von Ralf25


    Mein Hardcore-Test mit Outlook-Export (92 Spalten!) und Import in den CE macht aber einige manuelle Anpassungen notwendig (u.a. Spalten löschen und umbenennen), das teste ich im Ganzen erst später.


    92 spalten???? werden aber auch über den assi nicht verarbeitet...mehr als die spalten im editor kann der viewer nicht verarbeiten und fallen sowieso unter den tisch - kann man in outlook nicht beeinflussen welche adressteile exportiert werden??
    umbenennen muss nicht sein! die titelzeile ist nur orientierungshilfe!
    die reihenfolge ist entscheidend..

    Nein, in OL kann man nix filtern, das machte dann - neben der Zuordnung der Spalten - der Assi.


    OK: Wenn nur die Reihenfolge (und vermutlich Gesamtzahl) ausreicht, ist das schon mal 'ne Hilfe. Aber OL bringt erst die geschäftl., dann die privaten Adressen. Man muß also ordentlich Spalten schubsen. ;)

    Gut, dass jetzt bereits in der Testversion alles freigeschaltet ist. Erst das ermöglicht nun einen richtigen (Beta-)Test. ;)


    Folgende Verbesserungsvorschläge oder "nice-to-have's" hätte ich vorzubringen:
    - bei den Spalten in Deinem Exportfile unterscheidet sich bei diesen Spalten die Reihenfolge: "plz;Street;City;...;plz_b;city_b;street_b"; ist auch beim Import so erforderlich


    - kommt es beim Import zum Fehler, beendet sich gleich das Programm. Kann man im Code 'vor Ort' nicht die Exception abfangen und zurückkehren? Besser wäre auch, beim Import auf mögliche Fehler hinzuweisen? Ich hatte mehrere Exceptions, bis endlich durch nicht mehr nachvollziehbare Änderungen meine Sätze komplett importiert werden konnten.


    - neue Daten werden anscheinend schon direkt oder nur teilweise (?) nach dem Import in die DB geschrieben: DB zu Beginn 27KB, direkt nach dem Import 30KB und nach dem Beenden (und dem Hinweis) dann aber 36KB. Ein Kopieren der DB in dem Import-Zustand zeigte aber schon zusätzl. Einträge.
    Wenn man's weiß, ist das OK, auch wenn es IMO besser wäre, erst mal alles im RAM zu speichern.


    - eine Mehrfachselektion von Sätzen fände ich sehr sinnvoll, bspw. zum Löschen oder Ändern von 'Land'


    - wenn keine private oder geschäftliche Adresse vorliegt, sollte beim Import im jeweills leeren Teil bei Stadt/Land nicht "keine Stadt/kein Land" eingetragen werden, sondern garnix


    - Du 'bewirbst' es als Standalone-Prg. ;) Wäre es da nicht auch möglich, die Tabellen Addresses, Cities, Persons komplett mit neuen IDs aufzubauen und auch die DB zu komprimieren (ist aktuell nur über SQLite möglich)? Gut, man kann's auch durch Ex- und Import in neue DB erreichen, aber so wär's komfortabler.



    Ich würde mir nicht die Mühe zum Testen machen, wenn ich das Tool nicht sehr nützlich finde. Nur, wenn Medion bald in die Puschen kommt und selber was anbietet, kaufe ich ungern die Katze im Sack. ;) Aber für andere User sicher auch von Interesse: wie lange gilt denn der Support von Dir bei einer Vollversion?

    Der ContactEditor 2 ist nun auch im DL Bereich.
    Danke an Contacteditor :top

    Gruß Navirunner

    GoPal Wiki
    Tipps und Hilfen reinschauen lohnt sich

    **** Bitte keine Supportanfragen per PN, nur über's Forum! ****
    ******** Dann haben auch alle anderen was davon **********


    zu 1: ;) ist aufwendiger als es aussieht eine trialroutine wenn man keine tools zukaufen will deswegen wollte ich das eigentlich vermeiden...


    zu 2: sorry. flüchtigkeits-ungereimtheit :) hab ich wohl nicht drauf geachtet - könnte in der nächsten version geändert werden...


    zu 3: könnte man...aber: die hauptaufgabe des programms ist das editieren der kontakte (neu/ändern/löschen) import/export ist (erstmal) zweitrangig. das abzufangen würde bedeuten: das ganze importfile druchsehen und ständig vergleichen....viel aufwand aber naja mal sehen


    zu 4: die daten/änderungen/imports werden grundsätzlich erstmal in eine neue tabelle geschrieben. nicht in die CV-tabellen. auch die angezeigten datensätze kommen aus der neuen tabelle. die original-tabellen werden erst beim beenden und sichern der angezeigten datensätze komplett neu geschrieben. die temoräre tabelle wird dann wieder gelöscht und als letzter befehl "sqlite vacuum" damit die sqlite-db alle "löcher" stopft und komprimiert. allein im RAM zu arbeiten hat sich als nicht stabil erwiesen - eventuell liegts da an der sqlite.dll von realbasic..



    zu 5: hmm wie oft kommt sowas vor??? normalerweise werden im echtbetrieb nur einzelne datensätze ergänztoder bearbeitet und wenn viele datensätze importiert werden ist es durchaus sinnvoll diese nach import nochmals durchzugehen um nachzuarbeiten - aber werd mal drüber nachdenken..


    zu 6:ein grossteil unseres entwicklungsteam ist damit beschäftigt... :))


    zu 7: ??? mit den IDs vesteh ich jetzt nicht ganz. komprimiert wird die db mittels sqlite-vacuum s.o.


    zu 8: hmm medion hat den CV ja nie mehr supported und eigentlich auch nie richtig bekannt gemacht. ich denke die haben den erfinder auch 8kantig gefeuert nachdem sie den aufbau der db gesehen haben
    :)) ich würde nicht all zu grosse erwartungen in den angeblich kommenden contactmanager setzen. ob der wirklich noch den CV 3 unterstützt???? ist ja doch schon nen paar jahre alt. wenn dann benötigt das tool mit sicherheit irgendein .net-framework mit all seinen fussangeln


    zum support: ich kann da natürlich keine garantien abgeben. ich bin privatperson und nutze selbst aktiv den pna und auch den contacteditor.
    ob das programm noch in x jahren supported wird - sorry aber dafür gibts nie eine garantie oder hat es jemals ein update für den CV 3 gegeben?? der CV 4 musste über die gopal software voll bezahlt werden und seitdem ist schweigen im walde....

    Zitat von Navirunner

    Der ContactEditor 2 ist nun auch im DL Bereich.
    Danke an Contacteditor :top


    danke für's einstellen ber die beschreibung muss noch geändert werden!


    15 tage testversion ohne einschränkungen

    ad 3.) OK, verständlich, das Iterieren über die Einträge im Vorfeld wäre zwar optimal vom Vorgehen her, verstehe aber den Aufwand dazu. Das Abfangen der Exception müßte aber doch machbar sein, oder?


    ad 4.) mir fiel's nur auf, weil das Komprimieren mit SQLite nochmal ein paar KB freisetzte. Ich hatte nicht den Eindruck, das während meiner ganzen Aktionen irgendwann komprimiert wurde.
    Der Punkt ist aber nachrangig und kann von jedem manuell ausgeführt werden


    ad 5.) Hintergrund: erneuter Import aus OL -> doppelte Einträge, die im Vorfeld im *.csv nicht gelöscht wurden und nun in der Übersicht auffallen.
    Wenn's zu schwierig ist, muß man halt händisch editieren, copy'n'paste geht ja zum Glück


    ad 7.) mit ID ist die ID-Spalte gemeint, die bei mir schon große Löcher hat. :)) Dann verstecke diese Spalte und bringe eine lfd. Nr.; man hätte so die Anzahl der Kontakte sofort sichtbar


    ad 8.) ich gehe eher von einem neuen CV aus, und dann auch mit neuen Features (Gruppierung bspw.)



    Support: ist 'ne schwierige Frage und "x Jahre" wird keiner erwarten und war auch nicht gemeint. Ich sehe eher die Gefahr und bisher hatten wir Glück, dass die GoPal-Schnittstelle (-Aufruf) noch funzt, eben weil Medion den CV nicht supporten muß. Sowas muß sich nur in der V5 ändern, mit dem nächsten UP bspw. ;)

    Zitat von Ralf25

    ad 3.) Das Abfangen der Exception müßte aber doch machbar sein, oder?


    ?? wann und welcher fehler tritt denn auf??? es wird einfach das txt-file eingelesen und die ;-felder in datensatzfelder geschrieben. alles als string.
    entscheidend ist nur die richtige anzahl der datenfelder und die wird überprüft für den richtigen inhalt ist der user zuständig - oder?


    Zitat von Ralf25

    ad 4.) mir fiel's nur auf, weil das Komprimieren mit SQLite nochmal ein paar KB freisetzte. Ich hatte nicht den Eindruck, das während meiner ganzen Aktionen irgendwann komprimiert wurde.
    Der Punkt ist aber nachrangig und kann von jedem manuell ausgeführt werden


    gerade mal nachgesehen...hat irgendwie den befehl nicht geschluckt - jetzt ists geändert. komprimiert wird nach dem "programm beenden" und vor dem meldungsfenster "jetzt die db kopieren"


    Zitat von Ralf25

    ad 5.) Hintergrund: erneuter Import aus OL -> doppelte Einträge, die im Vorfeld im *.csv nicht gelöscht wurden und nun in der Übersicht auffallen.
    Wenn's zu schwierig ist, muß man halt händisch editieren, copy'n'paste geht ja zum Glück


    :) merge database... ein umfangreiches thema... gibt da einige kommerzielle lösungen für sqlite - die nicht umsonst recht teuer sind...
    alternativ-vorschlag von mir: 1 zusätzlicher button "alle ds löschen"
    dann vorgehensweise:
    - datenexport
    - exportdaten und ol-daten in excel/calc tabelle sortieren lassen (da sind doppler am schnellsten zu killen)
    - alle ds in CE löschen
    - datenimport



    Zitat von Ralf25

    ad 7.) mit ID ist die ID-Spalte gemeint, die bei mir schon große Löcher hat. :)) Dann verstecke diese Spalte und bringe eine lfd. Nr.; man hätte so die Anzahl der Kontakte sofort sichtbar


    liegt am db-design. ich kann nicht einfach eine ID ändern. müsste dann durch alle tabellen laufen und nach änderungen suchen. ausser beim import! wäre also über obige lösung am einfachsten zu realisieren.
    anzeige der anzahl datensätze ist kein problem.


    Zitat von Ralf25

    ad 8.) ich gehe eher von einem neuen CV aus, und dann auch mit neuen Features (Gruppierung bspw.)


    muss man abwarten...sich da jetzt gedanken drüber zu machen hat wenig sinn. wenn er denn dann wirklich irgendwann auf den markt kommt wird man sehen was er leistet - die eierlegendewollmilchsau erwarte ich eigentlich nicht. top oder flop wird mit einer editierfunktion direkt auf dem pna verbunden sein. das was eigentlich der CV 3 schon hätte haben müssen...und natürlich mit den zahlen vor dem €-zeichen :)



    Zitat von Ralf25

    Support: ist 'ne schwierige Frage und "x Jahre" wird keiner erwarten und war auch nicht gemeint. Ich sehe eher die Gefahr und bisher hatten wir Glück, dass die GoPal-Schnittstelle (-Aufruf) noch funzt, eben weil Medion den CV nicht supporten muß. Sowas muß sich nur in der V5 ändern, mit dem nächsten UP bspw. ;)


    bis zu welcher version läuft denn der CV eigentlich?? bin recht update-faul und hab immernoch die original 3.0PE mit den originalkarten. ausser in absoluten neubaugebieten kommt man damit eigentlich noch bestens klar..mit lkw ist man eh etwas vorsichtiger bei den anweisungen :))

    Zitat von Contacteditor

    ?? wann und welcher fehler tritt denn auf??? es wird einfach das txt-file eingelesen und die ;-felder in datensatzfelder geschrieben. alles als string.
    entscheidend ist nur die richtige anzahl der datenfelder und die wird überprüft für den richtigen inhalt ist der user zuständig - oder?


    Und woher soll der unerfahrene User wissen, woran es liegt? Es kann am Telefon-Nr. Format liegen, an irgendeinem Zeichen innerhalb der Textfelder, ...
    Ich schrieb ja oben, nicht mehr nachvollziehbar. Ich könnte es natürlich nochmal durchziehen, aber ehrlich gesagt, kostet mir das zuviel Zeit.




    Nun, ich meinte die Doppler, die durch den Import in eine bestehende DB enstehen, denn nicht jeder Navi-Kontakt, wenn er dann händisch eingetragen wurde, ist auch in OL.



    Zitat

    liegt am db-design. ich kann nicht einfach eine ID ändern. müsste dann durch alle tabellen laufen und nach änderungen suchen. ausser beim import! wäre also über obige lösung am einfachsten zu realisieren.
    anzeige der anzahl datensätze ist kein problem.


    Ich kenne Dein Vorgehen nicht, dachte aber, da zu Beginn alle Sätze en bloc eingelesen werden, wäre vor dem Insert eh ein Delete fällig. Und beim Insert mußt Du doch auch jetzt schon für die referentielle Integrität sorgen.



    Zitat

    bis zu welcher version läuft denn der CV eigentlich??


    Von der V3 bis zur akt. Version.

    Zitat von Ralf25

    Und woher soll der unerfahrene User wissen, woran es liegt? Es kann am Telefon-Nr. Format liegen, an irgendeinem Zeichen innerhalb der Textfelder, ...
    Ich schrieb ja oben, nicht mehr nachvollziehbar. Ich könnte es natürlich nochmal durchziehen, aber ehrlich gesagt, kostet mir das zuviel Zeit.


    wie beschrieben: das txtfile wird im prinzip 1:1 übernommen als string! da sind irgendwelche sonderzeichen vollkommen egal - wichtig ist die anzahl der felder...und die zähle ich durch... nicht reproduzierbaren fehlern kann ich natürlich auch nicht nachgehen...




    Zitat von Ralf25

    Nun, ich meinte die Doppler, die durch den Import in eine bestehende DB enstehen, denn nicht jeder Navi-Kontakt, wenn er dann händisch eingetragen wurde, ist auch in OL.


    genau das meinte ich auch :) und wäre mit der von mir vorgeschlagenen lösung am schnellsten zu realiesieren.




    Zitat von Ralf25

    Ich kenne Dein Vorgehen nicht, dachte aber, da zu Beginn alle Sätze en bloc eingelesen werden, wäre vor dem Insert eh ein Delete fällig. Und beim Insert mußt Du doch auch jetzt schon für die referentielle Integrität sorgen.


    en bloc einlesen geht ja leider nicht (siehe db-design). alle datensätze müssen mittels sql zusammengebaut werden und da ist die original-id entscheidend. die original-id nach dem sql-zusammenbau zu ändern führt in teufel's küche - glaub es mir :)

    Zu den Doppelten: am schnellsten schon. Aber auch für jemanden, der mit dem Computer nix am Hut hat?
    Aber OK, ich weiß mir zu helfen und mag sein, dass ich mich irre!



    Beim Kompletteinlesen (ins RAM) kann man sich ja der Views bedienen.


    Und die vorh. Sätze einlesen machst Du ja jetzt schon, ebenso wie das Tool in der Lage ist, eine leere DB komplett neu aufzubauen. Ein "delete *" im Vorfeld ist doch dann kein Problem, oder? Die Logik wäre doch dann - wenn ich es richtig interpretiere - bereits implementiert.


    OK, so wichtig ist die aufsteigende Nr. jetzt nicht, wäre nur ein schönes nice-to-have Feature und würde die Funktionalität des Tools ein wenig erweitern.

    Zitat von Ralf25

    Zu den Doppelten: am schnellsten schon. Aber auch für jemanden, der mit dem Computer nix am Hut hat?
    Aber OK, ich weiß mir zu helfen und mag sein, dass ich mich irre!


    absichtlich datensätze löschen weil das programm meint sie sind doppelt - sowas sollte eigentlich kein programm tun - der user könnte sich ja etwas wichtiges bei den doubletten gedacht haben was das programm nicht wissen kann. ein hinweis auf mögliche doubletten ja, aber mehr auf keinen fall.



    Zitat von Ralf25

    Beim Kompletteinlesen (ins RAM) kann man sich ja der Views bedienen.


    nicht gut - weil man nicht die gleiche umgedrehte routine zum schreiben nutzen könnte - würde also doppelte arbeit verursachen...

    Zitat von Contacteditor

    nicht gut - weil man nicht die gleiche umgedrehte routine zum schreiben nutzen könnte - würde also doppelte arbeit verursachen...


    Das hatte ich auch nicht geschrieben. Eintragen in die DB mußt Du die neu eingegebenen Sätze eh in einer Schleife (Array), oder?


    Aber egal, mir ging's nur um ein paar Vorschläge, was davon wie zu realisieren ist, weißt Du am besten!

  • Monika

    Hat das Label [Allgemeines] hinzugefügt.