FileMaker

Artikel zu FileMaker: siehe Projekte

Im Unterschied zu früheren Versionen können in FM 14/15 viele Einstellungen in den Optionen nicht mehr wie gewohnt vorgenommen werden. Früher war klar: Doppelklick auf einen Scriptbefehl öffnet ein Fenster, in dem sämtliche Einstellungen vornehmbar sind. Ab FM 14/15 gibt es eine Trennung zwischen Haupt- und Nebeneinstellungen. Die Haupteinstellungen (beim Scriptbefehl „Datensätze exportieren“ z.B. ist das die Exportreihenfolge) sind zugänglich, wenn man doppelklickt, die Nebeneinstellungen (bei „Datensätze exportieren“ ist das die Wahl zwischen „Mit Dialog:Ein“ und „Mit Dialog:Aus“) können nur verändert werden, wenn man genau den Teil der Option anklickt, den man verändern möchte, im Falle von „Mit Dialog:Ein“ wäre das das Wort „Ein“. Klickt man nicht genau auf dieses Wort, sondern z.B. auf „Mit Dialog“, passiert gar nichts - man hat den Eindruck, diese Option sei nicht zugänglich. Aus meiner Sicht ist das eine deutliche Verschlechterung des Komforts. Aber da der gesamte Scriptarbeitsbereich überarbeitet wurde, ergab sich wahrscheinlich die Notwendigkeit, zwischen Haupt- und Nebeneinstellungen unterscheiden zu müssen. Man wird sich daran gewöhnen können…

FM 12 und 13:

Syntax:

• <fmp:konto:passwort@ip-adresse/dateiname> Beispiel: *fmp:gast:gast@192.168.0.33/global

FM 7 bis 11:

Syntax:

• <fmp7:konto:passwort@ip-adresse/dateiname> Beispiel: *fmp7:gast:gast@192.168.0.30/global

Anlage einer Verknüpfung auf Desktop:

• rechte Maustaste auf freie Stelle
• neu - Verknüpfung
• obige url eingeben/einfügen
• Weiter
• Namen der Verknüpfung vergeben
• Fertigstellen

Seit FileMaker 7 (teilweise auch erst ab späteren Versionen) gibt es einige tolle Funktionen:

• SetzeVars (englisch: Let): Damit können komplizierte, mit vielen Verschachtelungen und Klammern versehene Kalkualtionen oder auch Formeln, in denen Felder mit langen Namen auftreten, vereinfacht werden; Trick dabei: Zwischen- oder Teilergebnisse werden in Variablen festgehalten und mit diesen Variablen kann dann in der Funktion gerechnet werden; siehe FileMaker 9 Developer Reference, Using FileMaker 7, FileMaker 9 Bible. So wird z.B. aus

= ZeichenRechts(eMail; (Länge (eMail) - Position(eMail;"@";1;1))) 

= SetzeVars ([
  a = Position(eMail ; "@" ; 1 ; 1);
  b = Länge(eMail) - a];
  ZeichenRechts(eMail ; b)
  )

Die Variablen werden hintereinander, durch Semikolon getrennt, deklariert; eingeschlossen werden sie gemeinsanm in eckigen Klammern; wiederum mit Semikolon von der Variablendeklaration getrennt kommt die eigentliche, das Endergebnis liefernde Kalkulation.

Wichtig zu wissen: mit „SetzeVars“ können alle drei Typen von Variablen deklariert werden: reine Kalkulationsvariablen ohne $ (wie im vorstehenden Beispiel), lokale Variablen mit einem $ und globale Variablen mit $$! (siehe auch unten: Variablen)

• Falls (englisch: Case): eine gute Alternative zur Wenn-Funktion; wichtigster Unterschied: es werden nur zwei Klammern gesetzt (Eingangs- und Ausgangsklammer); dadurch sind die Zusammenhänge viel übersichtlicher als bei einer Wenn-Funktion! Beispiel zur Ermittlung des Wochentags (im Feld „wann“ steht ein Datum):

SetzeVars ([
 a = Abs(Mod((wann) - Datum(6;21;2010); 7));
 b = Abs(Mod((wann) - Datum(6;22;2010); 7));
 c = Abs(Mod((wann) - Datum(6;23;2010); 7));
 d = Abs(Mod((wann) - Datum(6;24;2010); 7));
 e = Abs(Mod((wann) - Datum(6;25;2010); 7));
 f = Abs(Mod((wann) - Datum(6;26;2010); 7));
 g = Abs(Mod((wann) - Datum(6;27;2010); 7))
 ];
Falls(
a = 0; "Montag";
b = 0; "Dienstag";
c = 0; "Mittwoch";
d = 0; "Donnerstag";
e = 0; "Freitag";
f = 0; "Samstag";
g = 0; "Sonntag"
) 
)

Wichtig:
Die letzte Zeile der Falls-Funktion muss keine Bedingung enthalten, hier kann auch einfach ein Wert stehen; das ist so etwas wie „sonst gilt“:

SetzeVars ([
 a = Abs(Mod((wann) - Datum(6;21;2010); 7));
 b = Abs(Mod((wann) - Datum(6;22;2010); 7));
 c = Abs(Mod((wann) - Datum(6;23;2010); 7));
 d = Abs(Mod((wann) - Datum(6;24;2010); 7));
 e = Abs(Mod((wann) - Datum(6;25;2010); 7));
 f = Abs(Mod((wann) - Datum(6;26;2010); 7));
 g = Abs(Mod((wann) - Datum(6;27;2010); 7))
 ];
Falls(
a = 0; "Montag";
b = 0; "Dienstag";
c = 0; "Mittwoch";
d = 0; "Donnerstag";
e = 0; "Freitag";
f = 0; "Samstag";
\\sonst:
"Sonntag"
) 
)

• Auswahl (englisch: Choose): Alternative zur Wenn- und Falls-Funktion, wenn es um reine Zahlen geht
• HoleFeldwert (englisch: GetField): kann immer dann als Alternative eingesetzt werden, wenn in einer üblichen Wenn- oder Falls-Funktion ein bestimmtes Feld mehrmals getestet wird (im Sinne: falls a = b, dann 1, falls a = c, dann 2, falls a = d, dann 3…); es wird dann einfach einmal nach dem Feldinhalt gefragt: HoleFeldwert (a), egal, wie viele Test auf das Feld erfolgen!
• HoleNtenDatensatz (englisch: GetNthRecord): Dies ist die Funktion, die ich immer gesucht habe!

 Syntax: HoleNtenDatensatz (Feldname; Datensatznummer). 

Das bedeutet: man kann tatsächlich wie in Excel vom aktuellen Datensatz aus auf die Feldinhalte eines weit entfernten Datensatzes zugreifen, ohne dass dazu ein Skript laufen muss! Sämtliche Prüfformeln, die in der Excel-QuIndex-Version eingebaut sind, lassen sich auf diese Weise nach FileMaker übertragen! Beispiel:

= HoleNtenDatensatz (HT; Hole (DatensatzPositionInErgebnismenge) - 1)
gibt den Inhalt des Felds "HT" aus dem vorherigen Datensatz zurück. 

Für eine Doppeltenmarkierung hieße die Funktion

SetzeVars ([
a = HT;
b = HoleNtenDatensatz ( HT; Hole ( DatensatzPositionInErgebnismenge ) - 1  );
c =  HoleNtenDatensatz ( HT; Hole ( DatensatzPositionInErgebnismenge ) + 1  )
];
Falls (
a = b ODER a = c; "x";
"" 
))

FileMaker 10 und neuer: Die Funktion passt wunderbar zu der neuen Eigenschaft, dass FileMaker jeden hinzukommenden Datensatz automatisch in eine sortierte Anordnung einpasst!

FileMaker 7 bis 9: Hier wird die Brauchbarkeit der Funktion durch die Tatsache getrübt, dass sie immer nur ein Ergebnis auf der Basis einer unsortierten Ergebnismenge liefert! Speziell in QuIndex heißt das: z.B. eine Doppeltenmarkierung über diese Funktion funktioniert nur direkt nach dem alphabetischen Import der Daten!

HoleNtenDatensatz (Feldname; Datensatznummer) gehört zu den Logikfunktionen (es handelt sich nicht um eine Statusfunktion!).

Achtung: <hi>Das Ganze funktioniert nur, wenn in der Felddefintion bei „Speicheroptionen“ das Häkchen bei „Ergebnisse nicht speichern – nur Bedarf neu berechnen“ gesetzt wird!</hi> (Siehe auch Cache leeren bzw. Hole-Funktionen)

Was ist der Unterschied zwischen Skripts und Funktionen?
Skripts

• Mit Skripts können
  • Aktionen sowohl im aktuellen Datensatz als auch über mehrere Datensätze hinweg ausgeführt werden
  • Aktionen in Schleifen durchlaufen werden
  • Funktionen aufgerufen werden
• Skripts werden batchmäßig abgearbeitet: einen Datensatz nach dem anderen; erst wenn ein Skript in einem Datensatz „gewirkt“ hat, steht das Ergebnis der Aktion zur Verfügung
• Skripts helfen, Speicherplatz zu sparen, weil sie den Inhalt ganz normaler Felder in einem automatischen Prozess verändern

Funktionen

• Mit Funktionen können
  • Berechnungen nur innerhalb des aktuellen Datensatzes durchgeführt werden: alle Felder, die ich mit einer Funktion anspreche, befinden sich im aktuellen Datensatz
  • Schleifen nicht definiert und ausgeführt werden
  • keine Skripts aufgerufen werden.
• Funktionen werden im Hintergrund automatisch ausgeführt (was Speicher- und Prozessorkapazität kostet), sodass die Ergebnisse einer Berechnung sofort zur Verfügung stehen; soll Speicher- und Prozesorkapazizäz gespart werden, muss die automatische Speicherung ausgeschaltet werden; dann steht das Ergebnis der Berechnung erst nach einem weiteren, am besten Skript-gesteuerten Vorgang zur Verfügung.

Das Verhältnis zwischen Skripts und Funktionen ist also nicht symmetrisch. Skripts können mehr als Funktionen.

Insbesondere fällt auf, dass zwar Funktionen innerhalb von Skripts, aber keine Skripts innerhalb der Formel einer Funktion aufgerufen werden können.

Was sind eigene Funktionen?

Eigene Funktionen heben diese Asymmetrie in gewisser Weise auf.

Auch eigene Funktionen wirken nur innerhalb des aktuellen Datensatzes, aber sie sind sozusagen der Ersatz für Skripts, die ebenfalls nur im aktuellen Datensatz wirken.

Interessant ist vor allem die Möglichkeit, einen Schleifen-Mechanismus in eigene Funktionen einbauen zu können, also etwas, das sonst nur in Skripts möglich ist. Bei eigenen Funktionen heißen die Schleifen Rekursionen, weil die Funktion sich praktisch immer wieder selbst aufruft, bis ein bestimmter Parameterwert erreicht ist.

Ansonsten sind eigene Funktionen im Grunde nichts weiter als eine Abkürzung für komplexe Berechnungen. Und zwar eine Abkürzung, die an beliebigen Stellen - in einem anderen Feld, in einem Skript, in einer anderen Datei - zur Verfügung steht. Das würde man sonst nur mit Copy and Paste kompletter Formeln, also recht mühsam, erreichen.

Als Abkürzung für eine komplexe Berechnung kann zwar auch eine globale Variable (also eine Doppeldollar-Variable, z.B. $$a) verwendet werden, aber gegenüber einer eigenen Funktion hat die globale Variable zwei Nachteile:

• sie ist nur innerhalb einer Datei einsetzbar (hier aber sowohl in Feldfunktionen als auch in Skripts)
• sie hat keine Parameter, auf die sie flexibel reagiert.

Eine eigene Funktion ist aus Anwendersicht betrachtet genauso aufgebaut wie eine inhärente FileMaker-Funktion: sie hat einen Namen und die Parameter stehen in runden Klammern, durch Semikolon voneinander getrennt.

Entwickelt wird eine eigene Funktion praktisch immer auf der Basis der beiden inhärenten FileMaker-Funktionen SetzeVars und Falls.

Beispiel: „Tannenbaum“-Funktion zur Verkürzung der Trefferliste in einem Ausschnittsfenster (aus FMM 5/2010, S.13-14); sie hat nur einen Parameter: _text

Tannenbaum (_text)

SetzeVars ([
_zchn = ZeichenLinks(_text;1);
$wort = $wort & _zchn;
$text = $text & _zchn
];
Falls(
_zchn = ""; 
                SetzeVars ([
                 _tannenBaum = $textBaum;
                 $textBaum = "";
                 $text = "";
                 $wort = ""
                 ];
                 _tannenBaum
                 );
_zchn = " "; 
                 SetzeVars ([
                 $wort = ""
                 ];
                 Tannenbaum (ZeichenMitte (_text; 2; 999999))
                 ); 
Position (¶ & $textBaum; ¶ & $wort & ¶; 1; 1) = 0; 
                 SetzeVars ([
                 $textBaum = $textBaum & $wort & ¶;
                 $textBaum = $text & ¶ & $textBaum
                 ];
                 Tannenbaum (ZeichenMitte (_text; 2; 999999))
                 );
//Sonst
SetzeVars ([
            $textBaum = $text & ¶ & $textBaum
            ];
            Tannenbaum (ZeichenMitte (_text; 2; 999999))
            )
)
)

Als Parameter „_text“ kann irgendein Feld genommen werden. In QuIndex dient z.B. das Feld „HT“ als Parameter; so wird ein Formelfeld xy mit der „Tanne“ von HT besetzt: xy = Tannenbaum (HT). Das Feld xy kann dann als Referenzfeld verwendet werden, z.B. in einer Beziehung „pruef_zk“, die auf der Gleichheit der Inhalte der beiden Felder „xy“ und „pruef_zeichenkette“ beruht, wobei „pruef_zeichenkette“ manuell befüllt wird. Im Ausschnittsfenster „pruef_zk“ werden dann die Datensätze angezeigt, die zur aktuellen Zeichenkette passen.

Rekursion heißt, dass die Funktion sich selbst aufruft, d.h., sie wird genauso eingebaut, wie wenn es eine andere Funktion wäre. Der (oder die ) Funktionsparameter kann (können) bei jedem Einbau (Aufruf) derselbe sein, aber der Clou ist, dass der Parameter sich automatisch mitverändert. Und zwar nimmt FileMaker immer den Wert aus dem letzten Durchlauf. Das ist also ganz analog zu Variablen, denn da kann es ja auch z. B. heißen:

• $a = $a +1.

• feldbezogen: in Layoutmodus Feld anklicken und Trigger zuweisen (Menü „Format“)
• datensatzbezogen: in Layoutmodus die Layouteinstellungen aufrufen und Trigger zuweisen (Reiter „Script-Trigger“); datensatzbezogen heißt: bei Betreten oder Verlassen eines Datensatzes

Achtung: datensatzbezogene Trigger, also Trigger, die immer dann ablaufen, wenn

• ein Layout oder ein Datensatz betreten oder verlassen wird,

können schnell dazu führen, dass eine Endlosschleife entsteht oder dass andere Scripts nicht mehr korrekt laufen.

Mir ist bisher kein Fall begegnet, in dem ein datensatzbezogener Trigger Sinn gehabt hätte.

Eigentlich trivial, aber trotzdem erstaunlich:

• Man muss nicht unbedingt ein Feld angeben, um bestimmte Skriptbefehle ausführen zu lassen. Lässt man die Feldangabe weg, wird der Befehl im aktuellen Feld ausgeführt. Man muss natürlich sicherstellen, dass der Cursor sich vor dem Aufruf des Befehls in einem Feld befindet, oder man muss die Situation abfangen (mit einer Wenn-Abfrage und/oder einem eigenen Dialogfeld), dass er sich in keinem Feld befindet.
• Betroffen sind alle Skriptbefehle, in denen die Schaltfläche „Angeben“ des berechneten Ergebnisses auftaucht, also z.B.
  • Feldwert setzen
  • Text einfügen
  • Berechneten Wert einfügen
  • Ersetze alle Feldwerte

Das Weglassen des Zielfeldes (vgl. vorstehenden Punkt) ist eine wesentliche Voraussetzung dafür, dass die Cursorposition innerhalb eines Feldes (nämlich des Feldes, in dem der Cursor blinkt) per Script gesteuert werden kann.

Diese Navigation wird u.a. benötigt, um ausgewählten Text per Skript zu formatieren oder mit Formatierungscodes zu versehen.

Formatierungen werden am besten mit Codes vorgenommen, weil sie dann mit anderen Programmen wie Word, InDesign oder auch Indexingprogrammen (wie Cindex oder Sky) ausgetauscht werden können (unter Nutzung von Regex in den jeweiligen Programmen).

Typische Formatierungen sind kursiv, fett, hoch und tief. Mögliche Formatierungscodes (für einen ausgewählten Text „xxx“):

Um ausgewählten Text mit Formatierungscodes zu versehen, müssen

• die Cursorposition für den Beginn der Markierung und
• die Länge der Markierung

festgehalten werden. Dazu gibt es die Feldfunktionen

• Hole(AktiveTextAuswahlStart) und
• Hole(AktiveTextAuswahlGröße)

Beide Werte werden in lokale Variablen geschrieben (z.B. $cursorstart und $cursorende).

Der Cursor lässt sich mit dem Skriptbefehl Auswahl festlegen positionieren, in dem eine Start- und Endposition angegeben werden kann.

Betrachten wir z.B. ein Feld „HT“, in dem ein ausgewählter Text für Cindex kursiv formatiert werden soll. Das Skript dazu könnte lauten:

Fenster fixieren
Wenn [Hole (AktivesFeldName) = "HT"]
  Variable setzen [$cursorstart; Wert:Hole (AktiveTextAuswahlStart)] 
  Variable setzen [$cursorende; Wert:Hole (AktiveTextAuswahlGröße)] 
  Auswahl festlegen [HT; Startposition: $cursorstart; Endposition: 0]
  Text einfügen ["\i"]
  #Da nun 2 Buchstaben mehr im Feld sind, muss 2 addiert werden
  Auswahl festlegen [HT; Startposition: $cursorstart +2 +$cursorende; Endposition: 1]
  Text einfügen ["\I"]
Sonst
Ende (wenn)

Anmerkungen:

• Beim Befehl „Text einfügen“ wird kein Zielfeld angegeben
• Der Befehl zur Festlegung der Cursorposition lautet „Auswahl festlegen“; hierin bedeutet Endposition 0, dass der Cursor genau vor der Auswahl platziert wird, Endposition 1 heißt, der Cursor steht genau hinter der durch „Startposition“ vorgegebenen Stelle.
• Da nach dem Einbau des ersten Formatierungscodes das Feld um 2 Buchstaben länger geworden ist, muss zur Navigation des Cursors hinter das Ende des markierten Textes die „2“ addiert werden. Beim entsprechenden RTF-Code „{\i “ müsste „4“ addiert werden.

Der Inhalt eine Auswertefeldes kann in Formeln verwendet werden. M.a.W.: mit Auswertefeldern kann man (fast) ganz normal rechnen. Aber einige Dinge muss man dabei beachten, insbesondere, wenn es sich um „laufende“ Auswertungen handelt:

• Auswertefelder „funktionieren“ nur, wenn sortiert wird.
• Im Hintergrund wertet FileMaker Datensatz für Datensatz aus, d.h. der Inhalt eines Auswertefeldes ist in jedem Datensatz ein anderer. Konsequenz: Wenn z. B. in einem Skript zum ersten Mal auf ein Auswertefeld „zugegriffen“ wird, liegt der Fokus auf dem ersten Datensatz der Menge der angezeigten Datensätze (also der Ergebnismenge). Holt man also einfach so den Wert des Auswertefeldes, so stimmt er nicht mit dem Wert überein, der unterhalb der Ergebnismenge angezeigt wird. Aber genau diese Übereinstimmung erwartet man, weil kein anderer Wert des Auswertefeldes interessiert.
• Um also den richtigen Wert des Auswertefeldes holen zu können, muss der Fokus auf den letzten Datensatz der Ergebnismenge gesetzt werden! Denn dort stimmen der Hintergrundwert und der unten angezeigte Wert überein!

Also in einem Skript, in dem auf eine Formel mit Auswertefeld zurückgegriffen wird, immer

• erst sortieren,
• dann zum letzten Datensatz gehen,
• dann den Wert des Auswertefeldes holen.

• Um ein externes Script auszuführen, muss der Fokus auf die Datei gesetzt werden, die dieses Script enthält. Von FM 7 bis 9 war es nötig, dazu die externe Datei zu öffnen. Ab FM 10 scheint das anders zu sein, denn in der FMPro 10-Hilfe heißt es: „Sie brauchen keine externe Datei zu öffnen, wenn Sie ein Script in ihr verwenden – FileMaker Pro erledigt das für Sie.“ Falls das stimmt, kann man hier von einem „Datei-Script-Fokus“ sprechen - im Unterschied zum Datei-Layout-Fokus (siehe nächsten Punkt).
• Mit dem Scriptschritt „Datei öffnen“ wird die Quelldatei verlassen und die angegebene Ziel-Datei geöffnet, also der Fokus in diesem Moment auf die Ziel-Datei gelegt, und zwar anscheinend in dem Sinn, dass dort nun auch Elemente von Layouts (wie bestimmte Portale oder andere Objekte) angesprochen werden können. Daher kann dieser Datei-Fokus auch „Datei-Layout-Fokus“ genannt werden. Dieser Fokus wird benötigt, wenn im externen Script konkret mit Objekten der Zieldatei gearbeitet oder ein Feld-Inhalt in die Zwischenablage gehoben werden soll. Ein Datei-Layout-Fokus liegt auch vor, wenn die Zieldatei ausgeblendet geöffnet wird.
• Achtung: Scriptschritte nach dem Befehl „Datei öffnen“ werden in der Quell-Datei ausgeführt, nicht in der Ziel-Datei, es sei denn, der aufgerufene Scriptschritt ist ein externes Script (also Teil der Ziel-Datei).
• Wenn man ein externes Script im Datei-Script-Fokus ausgeführt hat und in die ursprüngliche Datei zurückkehren will, so reicht es, in der Quelldatei direkt nach dem Schritt „Script ausführen (extern)“ den Schritt „Blätternmodus aktivieren“ oder den Schritt „Gehe zu Layout“ einzufügen. Anmerkung: Wie beim Datei-Layout-Fokus dürfte es sogar ausreichen, irgendeinen nächsten Scriptschritt in der Quelldatei auszuführen, um zu ihr zurückzukehren.
• Zum Zurückkehren in die Quelldatei muss demnach in keinem Fall erneut mit dem Befehl „Datei öffnen“ (in diesem Fall Öffnen der Quelldatei) gearbeitet werden!

siehe Auswertefelder

Es kann vorkommen, dass eine Formel vollkommen korrekt ist, trotzdem aber das Ergebnis nicht angezeigt wird. Das Feld bleibt leer. Das liegt sehr wahrscheinlich daran, dass in der Formel auf ein Feld verweisen wird, dass leer ist. Standardmäßig berechnet FileMaker Formeln nicht, wenn dieser Zusammenhang gegeben ist. Im Formelfenster gibt es unten links eine Checkmarke „Nicht berechnen, wenn verwendete Felder leer sind“. Einfach das Häkchen wegnehmen, dann müsste es funktionieren.

Das Prinzip ist ganz einfach: Man nehme

• einen Button, der über den gesamten Datensatz gezogen wird und transparent auf der hintersten Ebene liegt und der mit einer bedingten Formatierung versehen wird
• alternativ: man belege einzelne Felder mit einer bedingten Formatierung
• in einem Script „Status_aktueller_Datensatz“ wird eine Variabel „$$mark“ deklariert, der der Wert der „rec_id“ zugewiesen wird (es muss ein Feld sein, dessen Wert für jeden Datensatz einmalig und eindeutig ist); zusätzlich wird im Script der Befehl „Fenster aktualiseren“ eingebaut
• der Button bekommt den Scriptbefehl zugewiesen bzw. die Felder den Scripttrigger (beim Eintritt in Feld) mit dem Scriptbefehl
• Button und Felder werden mit einer bedingten Formatierung versehen: rec_id = $$mark; wenn zutreffend, dann Buttonfüllung oder Feldfüllung farbig.

Das wars im Grunde. Wird nun der Bereich des Buttons angeklickt oder in eines der Felder mit Trigger, so wird das Script ausgeführt und führt automatisch (da $$mark immer gleich rec_id sein muss!) zur farblichen Hervorhebung.

Wichtig: „Fenster aktualisieren“ bewirkt, dass die vorherige Hervorhebung gelöscht und die neue angezeigt wird. (siehe auch: Cache leeren)

Cache leeren geht auf zwei Weisen:

• Fenster aktualisieren (wichtige Funktion z.b. beim Markieren von Datensätzen!)
• Speicherung von Feldinhalten ausschalten: Häkchen setzen bei „Ergebnisse nicht speichern…“ (in den Speicheroptionen eines Feldes)

zu ungespeicherten Feldern siehe z.B. Ray Cologon „FileMaker Pro 10 Bible“, S. 483 ff. („Unstored Calculations“)!!!

Hole-Funktionen haben ihre Eigenarten. Ganz wichtig ist, dass man immer dann, wenn eine Hole-Funktion in einer Formel in einem Feld verwendet wird, dafür sorgen muss, dass der Cache geleert wird! Das geht bei Feldern nur, indem die automatische Speicherung der Feldinhalte ausgeschaltet wird (siehe oben Cache leeren). Nur dann wird bei jeder Änderuing der Datenbank (z.b. einer neuen Sortierung) ein einmal ermittelter Feldinhalt durch den neuen überschrieben!

Beispiel: Die Funktion Hole (DatensatzPositionInErgebnismenge) liefert nur bei ausgeschaltetem Speicher die gewünschten Ergebnisse!

In einem Skript liefern Hole-Funktionen immer den jeweils aktuellen Wert!

In einem Bezugsdiagramm kann jede Tabelle mehrmals auftreten, man spricht von „Tabellenauftreten“ oder „Tabellenauftritten“. Jeder Auftritt muss einen anderen Namen erhalten; der Name des Auftritts ist auch in Beziehungen, die man anlegt, zu sehen. Im Grunde werden Beziehungen nicht zwischen Tabellen selbst, sondern immer zwischen Tabellenauftritten definiert.

In einem Bezugsdiagramm kann es Tabellen bzw. Tabellenauftritte ohne Bezug geben. Dabei heißt es aufgepasst! Es lassen sich

• zwar keine Ausschnitte auf der Basis solcher Tabellenauftritte anlegen,
• aber es ist möglich, z.B. Wertelisten zu definieren, die auf Feldern in solchen Tabellenauftreten beruhen, mit der Konsequenz, dass im Layout, in dem die Werte aus solchen Wertelisten gewählt oder angezeigt werden sollen, die Meldung kommt: „Feld nicht vorhanden“. Das ist klar, weil die Tabelle nicht zugänglich ist. Ein Zugang oder Zugriff ist erst möglich, wenn eine Beziehung existiert!

Im FM-Magazin 06/2010 wird auf S. 27 ein Weg für eine dynamische Ausschnitts(Portal)sortierung beschrieben. Wichtig sind dabei zwei Dinge:

• Das Feld, nach dem sortiert werden soll, muss ein Formelfeld sein, denn die ganze Dynamik kommt über die Formel zustande.
• Es wird außerdem ein globales Feld benötigt, das sozusagen als Parameterfeld dient: je nach Inhalt dieses Feldes berechnet sich das Ergebnis des Formelfeldes; es muss ein globales Feld sein, damit die Berechnung sofort in allen Datensätzen „greift“.

Da das Formelfeld eine Kalkulation mit einem globalen Feld vornimmt, wird es nicht gespeichert und somit nicht indiziert. Das hat aber auf die Sortierung keinerlei Einfluss (siehe auch Cologon FM 10, S. 342). Platziert werden muss das Formelfeld sowohl im Hauptlayout als auch im Ausschnitt.

Das globale Parameterfeld wird am besten per Script gefüllt (muss aber nicht sein).

Wo soll die Sortierung eingestellt werden: in der Relation oder direkt im Portal? Da im Portal immer nur eine Untermenge aller Datensätze dargestellt wird, empfiehlt es sich, die Sortierung hier einzustellen, nicht in der Relation, denn die Relation wirkt sich auf alle Datensätze aus mit der Konsequenz, dass gerade bei einem VPN-Zugriff auf die Datei die Anzeige sich nur sehr langsam aufbaut.

Beispiel QuIndex: Im Portal „ht_ht“ soll auf Knopfdruck nach dem Feld HT, UT, UUT, siehe oder S1 sortiert werden.

Das globale Feld sei „sort_ausschnitt_steuerung“, das Feld, nach dem sortiert wird, sei „sort_ausschnitt_text“ (es soll ausschließlich aufsteigend sortiert werden).

Dann lautet die Formel für „sort_ausschnitt_text“:

Falls(
sort_ausschnitt_steuerung = "HT"; HT;
sort_ausschnitt_steuerung = "UT"; Wenn(UT="";"(())";UT);
sort_ausschnitt_steuerung = "UUT"; Wenn(UUT="";"(())";UUT);
sort_ausschnitt_steuerung = "siehe"; Wenn(siehe_siehe_auch="";"(())";siehe_siehe_auch);
sort_ausschnitt_steuerung = "S1"; Wenn(Länge(S1)=1;"0000"&S1;
Wenn(Länge(S1)=2;"000"&S1;Wenn(Länge(S1)=3;"00"&S1;"00")))
)

Da die Portalsortierung nur noch auf dem Formelfeld „sort_ausschnitt_text“ basiert, dieses aber als Ergebnis Text liefert, müssen Zahlenfelder, nach denen man ebenfalls sortieren möchte, in alphanumerische Felder umgewandelt werden. Das geschieht in der Formel oben, indem führende Nullen per Textaddition („&“) der jeweiligen Zahl (S1) hinzugefügt werden.

Besetzt wird das Feld „sort_ausschnitt_steuerung“ per Script, und zwar werden so viele Scripts benötigt, wie es Felder gibt, also ein Script für HT (dadurch wird „sort_ausschnitt_steuerung“ mit „HT“ besetzt), eines für UT usw. Im jeweiligen Script steht im Grunde nur drin, dass der Feldwert von „sort_ausschnitt_steuerung“ gesetzt wird; außerdem scheint es gut zu sein, noch den Befehl „Fenster aktualisieren“ einzubauen, damit die Berechnung für das ungespeicherte Feld auf jeden Fall durchgeführt wird. Für jedes Script wird über dem Auschnittsfenster ein Button platziert (in der Nähe des jeweiligen Feldes). Das wars im Grunde!

Das Gute: Dieselben Scripts können für mehrere Ausschnittsfenster verwendet werden, die auf unterschiedlichen Relationen beruhen, aber dieselben Felder enthalten!

Achtung: Wenn die Sortierung gleichzeitig in der Relation und im Portal eingestellt ist, kann es zu Konflikten kommen! Immer kontrollieren, ob auch in der Relation eine Sortierung verlangt wird; falls ja: ausschalten.

Es kann passieren, dass eine Relation richtig definiert ist und trotzdem keine Daten im Ausschnitt auf der Basis dieser Relation angezeigt werden. Um herauszufinden, was der Grund ist, hilft ein Blick auf den Graph der Relation:

• Sind beide Enden der Verbindungslinien „Krähenfüße“, so ist grundsätzlich alles ok, weil die Krähenfüße zeigen, dass Felder in der Beziehungsdefintion verwendet werden, die ausgewertet werden können. Falls trotzdem keine Daten angezeigt werden, so liegt es sehr wahrscheinlich daran, dass die Felder, die im Ausschnitt platziert wurden, nicht zur aktuellen Relation gehören; einfach die passenden Felder platzieren, dann müssten Daten zu sehen sein.
• ist das eine Ende einer Verbindungslinie ein kleiner senkrechter Balken, dann kann das zugehörige Beziehungsfeld nicht ausgewertet werden und dementsprechend werden keine Daten angezeigt. Grund: es handelt sich um ein globales Feld oder um ein nicht gespeichertes Feld.
  • Globale Felder können nur in einer Richtung als Basis für eine Relation genommen werden (s.u.). D.h., man muss u.U. die Relation neu definieren und ein Feld nehmen, das beide Beziehungsrichtungen zulässt.
  • Nicht gespeicherte Felder können automatisch entstehen (wenn z.B. in der Feld-Formel mit einem globalen Feld gerechnet wird) oder man weist ihnen diese Eigenschaft manuell bewusst zu (bei den Speicheroptionen). Achtung: ist ein Formel-Feld ein nicht gespeichertes und ändert man die Definition eines der zugrundeliegenden Felder von „global“ auf „normal“, dann passt sich das Formel-Feld nicht automatisch an. Es könnte zwar von „nicht gespeichert“ auf „gespeichert“ gehen, tut es aber nicht.
    • Ist Letzeres der Fall, so könnte man manuell die Nichtspeicherung ausschalten, danach müsste die Relation funktionieren. Falls die Nichtspeicherung aus anderen Gründen eingeschaltet bleiben muss, so hilft nichts: Die Beziehung muss auf der Basis eines anderen, „erlaubten“ Feldes neu definiert werden.
    • Ein Feld wird automatisch nicht gespeichert, wenn es sich um ein Formelfeld handelt, das entweder mit einem globalen Feld verknüpft ist oder mit einem Feld aus einer anderen Tabelle. Letzeres geht ja auch wieder nur über eine Beziehung. Und es ist nicht erlaubt, eine neue Relation direkt auf der Basis einer anderen Relation aufzubauen. Auch hier hilft nichts: Die Beziehung muss auf der Basis eines „erlaubten“ Feldes neu definiert werden.
• Erlaubte Felder sind solche, die Filemaker speichern kann. D.h. aber, in allen oben genannten Fällen muss einfach dafür gesorgt werden, dass der interessierende Inhalt jeweils in ein solches Feld hineingebracht wird.
  • Dazu kann z.B. die Funktion „Ersetze alle Feldwerte“ sehr gut eingesetzt werden: Man nimmt ein neues Feld, das z.B. A heißt und ein reines Text-, Zahlen- oder Datumsfeld ist, also mit „harten“ Daten zu füllen ist. Beim Auffüllen mit „Ersetze alle Feldwerte“ wird eine Formel verwendet wird, die den Inhalt des anderen globalen oder nicht gespeicherten Feldes auswertet.
  • Eine andere Möglichkeit wäre, A per Script zu füllen, wobei in einer Schleife alle Datensätze von oben nach unten (oder umgekehrt) zu durchlaufen wären.
• A wäre dann jedenfalls das gesuchte, für eine Relation erlaubte Feld.

• Aufgepassst bei Relationen, an denen globale Felder „beteiligt“ sind! In QuIndex habe ich z.B. versucht, eine Beziehgung zwischen zwei Feldern aufzubauen, deren Inhalte per Formel auf der Basis von globalen Feldern kreiert werden. „aehnlichkeitsbreite02“ ist ein globales Feld, das per Skript mit einer Zahl (3, 4, 5, 6oder 10) gefüllt wird. Nun lautet eine Formel:

ht_sort_prüf = SetzeVars([a= ähnlichkeitsbreite02];
Falls (a = 3; HT_sort_3 ; 
a = 4; HT_sort_4;
a = 5; HT_sort_5; 
a = 6; HT_sort_6;
HT_sort_10)
)

und die andere Formel:

prüf_einzelverweis_var = SetzeVars([a = ähnlichkeitsbreite02];
Falls( a = 3; prüf_einzelverweis_3;
a = 4; prüf_einzelverweis_4; 
a = 5; prüf_einzelverweis_5;
a = 6; prüf_einzelverweis_6;
prüf_einzelverweis_10) 
)

Zwischen den beiden Feldern ht_sort_prüf und prüf_einzelverweis_var wird eine Beziehung definiert mit dem Ziel, dass sämtliche Vorkommnisse angezeigt werden, sobald im Feld prüf_einzelverweis etwas eingegeben wird. Die Felder prüf_einzelverweis_3, prüf_einzelverweis_4 usw. geben immer den linken Teil des Feldes prüf_einzelverweis wieder, und zwar mit einer Länge, die durch ähnlichkeitsbreite_02 vorgegeben ist. Doch Schreck: Im Portal wird nichts angezeigt!

Schaut man sich den Beziehungsgraphen an, so wird klar, was los ist: Die Beziehungslinie, die zwischen ht_sort_prüf und prüf_einzelverweis_var gezogen ist, hat auf beiden Seiten „stumpfe“ Enden, d.h., die Beziehung kann von FileMaker nicht ausgewertet werden. Und das liegt daran, dass beide Felder per Formel auf einem globalen Feld basieren (hier sogar auf demselben globalen Feld, was aber unerheblich ist). Globale Felder gehören allen Datensätzen, daher gibt es keinerlei spezielle Zuordnung zu bestimtmen Datensätzen, also kann keine Beziehung definiert werden.

Aber: wenn nur auf einer Seite einer Beziehung auf einem globalen Feld basiert, dann klappt es! In diesem Fall ist aber die Richtung der Beziehung entscheidend. (Vgl. Coffey/Prosser „FileMaker 9 Pro The Missing Manual“, S. 395)

• Weshalb können keine Daten in die Felder eines Portals eingegeben werden, insbesondere: weshalb kann kein neuer Bezugsdatensatz angelegt werden, obwohl in der Beziehung die Checkmarke „Erstellung von Datensätzen in dieser Tabelle über diese Beziehung zulassen“ gesetzt wurde? Antwort: In einer anderen Beziehung zur selben Tabelle wurde ebenfalls diese Checkmarke gesetzt. Beide Beziehungen kommen sich in die Quere. Neue Bezugsdatendsätze können prinzipiell nur über eine einzige Beziehung angelegt werden! Also: Alle Checkmarken wegnehmen bis auf eine! (Fällt unter das Stichwort „Referenzintegrität“)
  

Achtung: bin nicht ganz sicher, ob das wirklich so ist. Möglicherweise können sogar Bezugsdatensätze über mehrere Beziehungen angelegt werden (keine gute Datenintegrität!); der Grund für das oben beschriebene Problem scheint ein anderer zu sein!

• Erstaunlich (oder auch nicht): sobald im Portal in eines der leeren Felder des anzulegenden Datensatzes Inhalt eingegeben wird, der Datensatz damit also angelegt wird, sind automatisch alle Bezugsfelder der Tochtertabelle ausgefüllt. Das muss ja eigentlich auch so sein, weil sonst der Datensatz nicht existieren könnte. Zumindest gilt das für Gleichheits-Bezüge („equijoins“). Die Anlage innerhalb eines Portals bedeutet ja immer - unabhängig von der Zahl der Bezüge -, dass die Inhalte der Bezugsfelder in Mutter- und Tochtertabelle identisch sein müssen, sonst werden keine Bezugsdatensätze angezeigt. Interessant ist das ganze insofern, als Formelfelder der Tochtertabelle, die auf einem der Bezugsfelder basieren, sich wie von Geisterhand im Portal füllen (wenn sie denn hier platziert sind). Man hat den Eindruck, FileMaker holt die Inhalte von irgendwo her, dabei ist die Sache - wie vorstehend erläutert - klar.
• Ebenfalls erstaunlich (oder auch nicht): Befinden sich mehrere Portale, die auf unterschiedlichen Mehrfachbezügen basieren, auf einem Layout, dann kann die Anzeige in dem einem Portal diejenige in einem anderen beeinflussen! Beispielsweise seien zwei Portale A und B aufgebaut auf der Beziehung A bzw. B. Außerdem basiere Beziehung A auf den Bezugsfeldern ref_1 und Feld_a, Beziehung B auf ref_1, Feld_a und Feld_b (die Felder mögen in beiden Tabellenauftritten gleich lauten). Es gibt also eine teilweise Überseinstimmung bei den Referenzfeldern. Steuert man nun z.B. das, was in Portal A angezeigt wird, mit Bezugsfeld Feld_a und bei Portal B mit Feld_b, so wird in Portal B etwas anderes angezeigt, wenn der Inhalt von Portal A durch Eingabe oder Auswahl von Feld_a geändert wird! D.h., man könnte über Mehrfachbeziehungen eine Art Kaskade aufbauen, in der die eine Portalselektion auf der vorhergehenden aufbaut!

• Wie lassen sich Datensätze finden, bei denen in einem Portal nichts angezeigt wird? Eine Suche, bei der man in einem Portal-Feld einträgt „=“ (für „leer“), bringt als Ergebnis die Fehlermeldung „Kein Datensatz entspricht dieser Abfrage“. Das ist auch nicht verwunderlich, denn definitionsgemäß wird in einem Portal kein Bezugsdatensatz angezeigt, der nichts enthält. Es gibt aber zwei Möglichkeiten, dennoch zum Ziel zu kommen:
  1. Man lässt ein Script laufen (als Schleife vom ersten bis zum letzten Datensatz), das die Zahl der Bezugsdatensätze im zu untersuchenden Portal eines jeden Datensatzes feststellt und diese Zahl in ein ganz normales „Zählfeld“ schreibt. Anschließend kann im Zählfeld nach „0“ gesucht werden.
  2. Ohne Script geht es nur, indem gesucht und dann mit dem Befehl „Mehrere ausschließen“ gearbeitet wird. D.h., man sucht alle Datensätze, die einem auf die eigene Datei angewandten Kriterium entprechen (ganz normale Suche). Dann werden - und das ist die Lösung des Problems - die gefundenen Datensätze sortiert, und zwar nach einem Feld (aufsteigend) im zu untersuchenden Portal. Nach der Sortierung kommen zuerst alle Datensätze, zu denen mehr als 0 Bezugsdatensätze existieren, dann kommen alle Datensätze, zu denen es keinen Bezugsdatensatz gibt. Man merkt sich die Datensatznummer des letzten Datensatzes mit existierendem Bezugsdatensatz, geht zum ersten Datensatz und schließt mit dem Befehl „Mehrere ausschließen“ (gemerkte Nummer eintragen) die unerwünschten Datensätze aus. Übrig bleiben genau die Datensätze ohne Bezugsdatensatz. Wichtig ist das zum Beispiel in QuIndex bei der Verweis- und Permutationsprüfung
• Selektion per Portal siehe auch vorstehenden Punkt zu Mehrfachbeziehungen.

• Wie kann in einem Fenster, in dem sich mehrere Portale befinden,ein bestimmtes „angesprungen“ werden? Ganz einfach: indem ihm ein Objektname zugewiesen wird und man dann mit der „Gehe zu Objekt“-Funktion arbeitet.

• Wenn bei einer Suche nichts gefunden wird, so wird das FileMaker-intern als Fehler 401 gehandelt. In einem Script kann der Fehler mit „Fehleraufzeichnung ein“ abgefangen werden.
• Soll in einem Script eine Aktion dann ausgelöst werden, wenn gerade das Gegenteil eintritt, also Datensätze gefunden werden, so kann dazu die Statusfunktion „Hole(AnzahlGefundeneDatensaetze)“ genommen werden. Dis kann wichtig sein, wenn man z.B. eine Schleife verlassen will, bei der am Anfang der Fehler 401 eine Rolle spielte. Motto: Verlasse Schleife, wenn kein Fehler vorliegt. Und dieses „kein Fehler“ wird mit Hole(AnzahlGefundeneDatensaetze) > 0 ausgedrückt.

• MooPlug: ist umsonst zu haben. Ein Test zeigt: es führt in allen möglichen Situationen zu Abstürzen (z.B., wenn man den Inhalt eines Ordners auflisten lassen möchte). Fazit: untauglich

WG 20.10.09:
Auch in FileMaker 10 tritt dieser Effekt auf! Es scheint sogar so zu sein, dass manche Skripts, die in FM 9 problemlos liefen, in FM 10 plötzlich auf andere Felder wirken, selbst wenn diese Felder im Skript gar nicht angesprochen werden! Aufgetreten ist der Effekt in QuIndex. Möglicherweise spielt die Anzahl der Felder in einer Tabelle eine Rolle. Angeblich gibt es diesbezüglich zwar kaum Grenzen (vgl. „FM 10 Pro in Depth“), aber FM läuft beileibe nicht fehlerfrei!

WG 21.9.08:
FileMaker scheint hin und wieder ein Problem mit manchen Feldern zu bekommen; in QuIndex wurden einige Skripts, die Änderungen am Feld „UE“ vornehmen sollten, nicht ausgeführt. Das Ganze war ein Effekt, der auf ein bestimmtes Layout beschränkt blieb. Einzige Lösung: Feld neu platzieren!

Der vorhergehende Punkt hängt u.U. damit zusammen, dass einige Layouts im Laufe der Zeit (wenn sie immer wieder umgestaltet wurden) korrupt werden können. Darauf gibt es zahlreiche Hinweise in FM-Foren.

Ich habe mir überlegt, dass es vielleicht am besten ist, Funktion und Form weitestgehend voneinander zu trennen. D.h. schön gestaltete Layouts sollten nicht dazu verwendet werden, viele Formelfelder zu tragen oder für den Ablauf von Skripts Zwischenergebnisse aufzunehmen usw. „Formlayouts“ sollten nur die Felder enthalten, die zur Eingabe und Darstellung der Daten nötig sind, alle anderen Felder sollten auf reinen „Funktionslayouts“ platziert werden. Deren Aussehen ist unwichtig, sollte nur einigermaßen übersichtlich sein. Die Gestaltung von Funktionslayouts sollte möglichst selten geändert werden und möglichst wenig Zusatzelemente enthalten (also kaum Buttons, Linien, Kästen, Reiter usw.). Alle Skripts sollten immer zu den Funktionslayouts umgeleitet werden, und am Ende steht der User wieder im Formlayout.

Für QuIndex heißt das, dass die Bearbeitungslayouts kräftig entfrachtet werden. Dann müsste alles stabil laufen.

Im FM-Forum des FM-Magazins ist immer wieder der Hinweis zu finden, dass manche Skriptaktionen für andere davon abhängige Aktionen zu schnell ablaufen, eventeull kommt auch das Betriebssystem nicht hinterher, weil der Cache noch belegt ist usw.

Lösung des Problems: einfach mal Skriptpausen einbauen!

Siehe auch: „Cache leeren“.

• WG 10.1.10:
  • Wenn Felder per Dialog mit Werten besetzt werden, so kann eine Skriptschleife mit dazu verwendet werden, eine Prüfung vorzunehmen: Ein Beispiel ist das Script „anlegen_tage_alle proj_von_bis_sort_proj“ in Projekte-DB, in dem ein Anfangs- und ein Enddatum über zwei aufeinanderfolgende Dialoge angefragt und in zwei globale Datumsfelder gebracht werden.

  Schleife (Anfang)
  Eigenes Dialogfeld ["Anfangsdatum"; Feld: glob__feld1]
  Eigenes Dialogfeld ["Enddatum"; Feld: glob__feld2]
  Verlasse Schleife wenn [glob_feld1 > Systemdatum UND glob_feld2 > glob_feld1]
  Schleife (Ende)

Die beiden Felder glob_feld1 und glob_feld2 sind als Datumsfelder definiert und akzeptieren nur Datumswerte; daher muss nicht auf das Datumsformat an sich überprüft werden, sondern lediglich darauf, dass Anfangs- und Enddatum im richtigen Zeitbereich liegen.

• WG 13.9.07:
  • Ein eigenartige Geschichte in FM ist das Verhalten von Feldüberprüfungen, wenn ein Script aufgerufen wird. In der Warenwirtschaft (Scitech) gibt es z.B. eine Seite mit einem Portal, in dem ein Feld (das Feld „Positionsnummer“, das zu einer anderen Tabelle gehört!) nicht leer sein darf, wenn der entsprechende Bezugsdatensatz mit Informationen gefüllt wird. Das Füllen des Bezugsdatensatzes beginnt aber normalerweise in einem anderen Feld (Artikelnummer) und man könnte nach dem Füllen des Feldes Artikelnummer auf die Idee kommen, nicht per Tab oder Enter weiterzumachen, sondern sofort druch Anklicken eines Buttons ein Script auszulösen. Tut man das, kommt die Überprüfungsmeldung „Feld Positionsnummer darf nicht leer sein“ und man landet in einer eigenartigen Schleife, die zwar manuell abgebrochen werden kann, am Ende hat das Script aber falsche Daten erzeugt (weil es abgebrochen wurde).
  • Komischerweise scheint es so zu sein, dass Eingabefehler, die direkt vor dem Auslösen eines Scripts erzeugt wurden, im Script nicht als solche erkannt und abgefangen werden können. Die Fehlernummer für diesen Fall ist 505. Sämtliche Fehlernummern werden aber nur erkannt, wenn sie im Ablauf eines Scripts auftreten. Um das Problem in den Griff zu bekommen, bleibt nichts anderes übrig, als die Feldüberprüfung aus der Felddefinition herauszunehmen und per Extrascript vorzunehmen! Zumindest kann man das immer dann so machen, wenn die Daten des Bezugsdatensatz auschließlich scriptgesteuert weiterverarbeitet werden. Siehe Script „Postionsnummer-Prüfung“ in der Warenwirtschaft.

WG 1.7.09:
Unbedingt zu beachten ist, dass Feldüberprüfungen immer nur auf Merkmale innerhalb des aktuellen Datensatzes hin durchgeführt werden! Das hat gewaltige Konsequenzen:

• eine Eindeutigkeitsprüfung geht zwar direkt, aber nicht per Formel. Man kann also nicht z.B. in einem Formelfeld X den Inhalt zweier Felder Y und Z zusammenführen (X = Y&Z) und dann in einem Eingabefeld E das Häkchen bei „eindeutig“ setzen und zusätzlich „Überpüfung per Formel“, wobei die Überpüfungsformel =X lautet. Denn bei dieser Prüfungskombination müssten FileMaker die Formelergebnisse aus allen anderen Datensätzen bekannt sein, weil nur dann eine Ein- oder Mehrdeutigkeit erkannt werden könnte. Das geht aber nicht!
• insbesondere in Ausschnittsfenstern kann keine irgendwiegeartete Überprüfung per Formel vorgenommen werden, weil es keinen Bezug zur aktuellen Ausschnittsreihe gibt - FileMaker nimmt immer die erste Reihe als Bezug!!! Z.B. ist bei Positionsnummern, die immer der jeweils aktuellen Ausschnittsreihennummer entsprechen sollen, keine Prüfung auf Ausschnittsreihennummer möglich, weil FileMaker sich immer auf die erste Reihe bezieht!
• jede Form von Überprüfung, bei der Formeln eine Rolle spielen könnten, muss per Skript - also manuell in einem Extraschritt! - ausgelöst werden!

WG 28.12.07:
Jedes „Objekt“ in einem Layout - Feld, Portal, Reiter, … - kann mit einem Namen versehen werden. Der Name ist nicht von vornherein vorhanden, sondern muss bewusst zugewiesen werden. Das geschieht, indem man das Objekt anklickt und dann im „Objekt-Info-Fenster“ den Namen einträgt. Danach kann das Objekt mit dem Script-Befehl „Gehe zu Objekt“ angesprungen werden.

Ab FileMaker 5 (!) ist es möglich, Zugriffsrechte auf Datensatzebene zu erteilen, ab FM 7 klappt es so, wie man es sich wünscht (Auschnitt aus Mail an dirk am 18.7.07):

Man kann bei der Rechte-Erteilung einfach ein Kriterium angeben, das den Zugriff auf Datensatzebene gestattet oder nicht. Also Rechte-Erteilung ganz variabel und per Formel! Am einfachsten scheint es zu sein, ein ganz normales Feld in der Datenbank als „Zugriffsfeld“ zu definieren, das bei der Erzeugung eines jeden Datensatzes automatisch gefüllt wird - beispielsweise mit den ersten 4 Ziffern des Projektnummernkreises von Scitech Italia oder Scitech Deutschland (man könnte sich auch andere Inhalte überlegen). Dann könnten z.B. drei verschiedene Berechtigungen definiert werden: eine Admin-Berechtigung (alles sehen und bearbeiten), eine Berechtigung für Deutschland und eine für Italien, wobei letztere zwei auf dieses Zugriffsfeld zurückgreifen. Das tolle: Die Datensätze, auf die der Zugriff nicht erlaubt ist, werden wirklich nicht angezeigt, man kann nach ihnen auch nicht suchen - gar nichts. So soll es ja auch sein!

Kriterium in FM 5 und 6 mit „Musteranzahl (Feld, Text)“ (ohne weitere Operation dahinter!) abfragen, damit ein logisches Wahr oder Falsch herauskommt (Wenn-Abfrage geht nicht!), ab FM 7 ist die Wahr/Falsch-Logik gleich eingebaut und man braucht einfach nur das Feld anzugeben und welcher Bedingung der Inhalt genügen soll, also z.B. <zugriff> = 1.

Es gibt drei verschiedene Möglichkeiten, mit Variablen zu arbeiten:

1. per Variablenfeldern (Feldoption „globale Speicherung“)
2. per Definition innerhalb einer Formel, und zwar mithilfe der Funktion „SetzeVars“ (siehe oben: Spezielle Funktionen)
3. per Definiton innerhalb eines Skripts, üblicherweise, indem der Vefehl „Variable setzen“ aufgerufen wird. Dabei wird zwischen lokalen und globalen Skriptvariablen unterschieden: lokale beginnen mit einem einfachen Dollarzeichen (z.B. $kosten) und gelten nur innerhalb des Skripts, globale beginnen mit doppeltem Dollarzeichen (z.B. $$kosten) und gelten innerhalb der gesamten Datei, also auch in anderen Skripts. Aber: Variablen können nicht von einer Datei zu einer anderen übergeben werden! Das ist z.B. ein Problem, wenn innerhalb eines Skripts der Befehl „Datei öffnen“ aufgerufen wird, damit dann ein externes Skript abläuft. Hier hilft entweder eine Beziehung (und die Übergabe über ein Ausschnittsfenster) oder aber das „Rüberschaufeln“ jedes einzelnen Wertes über die Zwischenablage!

Gut:

• Skriptvariablen, die irgendwo in einem Skript definiert wurden, können auch innerhalb von Formeln verwendet werden: lokale Variablen nur innerhalb des Skripts, globale auch außerhalb des Skripts in „normalen“ Formeln.
• Besonderheiten der Definition von Variablen: Skriptvariablen lassen sich neben dem Befehl „Variable setzen“ auch über die Funktion „SetzeVars“ definieren: Befindet sich die Funktion innerhalb eines Skripts, so stehen lokale Variablen, die mit SetzeVars erzeugt wurden, dem Skript zur Verfügung; globale Variablen können mit der Funktion SetzeVars innerhalb oder - das ist das Besondere - auch außerhalb von Skripts definiert werden, z.B. in einer normalen Formel!

Eine mögliche Lösung wird ausführlich in R. Cologon „FM Pro 10 Bible“ (S. 400ff) beschrieben.

Erstaunlich: Voraussetzung für das Funktionieren sind sog. Platzhalter (englisch: Merge fields). Die gibt es mindestens schon seit FM 7!

Das Prinzip besteht darin, Platzhalter zu platzieren, die abhängig von einer gewählten Sprache mit dem jeweiligen Inhalt gefüllt werden. Der sprachabhängige Inhalt wird einfach in einer separaten Tabelle gepflegt.

Wichtige Erkenntnis: Es werden keine Felder benötigt; die gesamte Variabilität wird durch die Platzhalter übernommen.