Filemaker: Daten und Oberfläche trennen

Dieses Thema im Forum "Software" wurde erstellt von hapu, 1. März 2005.

  1. hapu

    hapu New Member

    Eine Frage an die fortgeschrittenen FM-User:

    Die Vorgabe:
    Ich möchte für meine Kollegen eine DB entwerfen, wobei jeder von uns eigene Kunden und Termine hat.

    Das Problem:
    Es ist damit zu rechnen, dass ich von Zeit zu Zeit Änderungen / Aktualisierungen / Verbesserungen durchführen werde. Wenn ich dann also meine neue DB-Version verschicke, beginnen alle wieder bei NULL Datensätzen!!

    Der Ansatz:
    In Access kann ich die DB-Oberfläche (das "Formular") mit externen Tabellen verknüpfen. So ist es also ein Leichtes, die Daten-DB von der DB-GUI zu trennen und Aktualisierungen der GUI zu verschicken (solange sich die Struktur und der Pfad nicht verändert!).

    In Filemaker 7 konnte ich aber nichts finden, was auf externe Tabellen hinweist (ja, ich habe auch in der Hilfe gesucht!) - kann das FM nicht?!

    Bitte Hilfe, ich mag nicht Access in einem Windows-Emulator laufen lassen müssen!!

    lg
    HaPu
     
  2. safari

    safari New Member

    Tja, in FMP so wie z.B. in 4D nicht möglich! Die Trennung von Daten und GUI ist wohl die am häufigsten gewünschte Neuerung der großen FileMaker-Entwicklergemeinde - nur FMI hat da noch kein Einsehen gehabt. Umweg: mittels eines früher oder später höchst kompliziert werdenden Beziehungsgeflecht 1 Datei mit den Oberflächen aufzubauen und weitere reine Daten-Dateien. Das ist aber nicht trivial und erfordert schon einen wirklichen FileMaker-Profi!
    Die von mir empfohlene Lösung lautet: Gute geskriptete Export/Importmöglichkeiten (also via Knopfdruck auf einem Wartungslayout werden "alle" DS exportiert, weiterer Knopf in einer neuen Datei importiert die DS - es hilft, wenn immer mit festen Ordnerstrukturen gearbeitet wird, also in meinen Lösungen gibt es immer, neben anderen, einen Export- und einen Import-Ordner. Dazu muss die Lösung natürlich ebenfalls gut dokumentiert sein! Dazu eine gute BackUp-Situation und schon kann wenig schiefgehen ...

    PS: Du solltest auch schon einige "Leerdatenfelder" mit einplanen, das hilft bei Erweiterungen der Lösung enorm. Es werden dann also nicht neue Felder definiert, sondern freie vorbereitete Felder benutzt - auch hier gilt: Gute Dokumentation der Felder ist alles!

    Achso, ja, noch eines - mit AppleScript kannst Du dann natürlich bei einem Update das meiste automatisieren ... Access im Emulator kann kein AppleScript!
     
  3. hapu

    hapu New Member

    Danke für die schnelle Antwort - Diesen Inhalt hatte ich schon befürchtet, wollte es aber nicht wahr haben.

    Nachsatz: Alle anderen arbeiten mit Windows-Notebooks (ich ebenso, nur zuhause will ich lieber am Mac schlumpfen) - da ist ihnen Access sowieso lieber und mir AppleScript verboten.

    *schluchz*
    HaPu
     

Diese Seite empfehlen