Adress-DB selber bauen?

    Hi Leute.


    Ich mache mir Gedanken darüber, wie ich die Adressen für eine CRM-Anwendung verwalten soll: entweder mit einem Notes Adressbuch oder mit einer selbst entwicklten Adress-DB.


    Ich tendiere eher dazu eine eigene DB zu bauen. Diese soll dann als Adressquelle für das CRM dienen und auch von der normalen R6-Mail-DB verwendet werden können. Dabei stellt sich jedoch die Frage, ob es Probleme mit der Einbindung in die normale Mail-db geben könnte - z.b. Auswahldialog im 'An'-Feld,...


    Ich habe herausgefunden, dass 5 Ansichten in der names.ntf entscheidend sind: ($PeopleGroupsByLang), ($PeopleGroupsCorpHier), ($PeopleGroupsFlat), ($PeopleGroupsFlat), ($People).
    Aber die könnte ich ja "nachbauen" oder übernehmen.


    Hat jemand von euch schon eigene Adress-DBs entwickelt und Erfahrung mit der allgemeinen Einbindung? Ist dieser Ansatz sehr fehleranfällig?


    lg, alex

    Genau so haben wir es auch gemacht um unsere eigene AdressDB als zusätzliches Adressbuch verwenden zu können.
    Das sind genau die Ansichten mit Ausnahme der ($People). Die haben wir nie gebraucht

    Ich meine mich zu erinnern, dass die Feldbezeichnungen in der eigenen DB mit den Standarf-Feldbezeichnungen aus Notes übereinstimmen müssen. Also immer FIRSTNAME, INTERNETADDRESS usw.

    Zitat

    Glücklicherweise ist das nicht der Fall, denn für die Adressauswahl zieht der sich die Werte aus den entsprechenden Ansichtsspalten


    Aber um sie in den Ansichtsspalten (ich nehme an du meinst die oben genannten Ansichten - wenn ich sie übernehme) richtig angezeigt zu bekommen, müssen die Feldnamen passen.


    Ich habe mitbekommen, dass auch ($Users) und ($ServerLookup) wichtig sein sollen? Könnt ihr das auch bestätigen?


    alex

    Die Feldnamen in der Ansicht kannst du ja beliebig anpassen.
    Das ist nicht das Problem.
    Die beiden Ansichten werden meines Wissens nach nur bei einem öffentlichen Adressbuch vom Server verwendet sind aber für zusätzliche Adressbücher nicht von Bedeutung.