Warenkorb
0
Wagen 0
Telefonische Beratung +49 (0) 441-30 43 76 40
Wer kennt das nicht: Ein Datensatz ist nicht mehr vorhanden oder wurde geändert, aber niemand will es gewesen sein. Besonders ärgerlich ist so etwas vor allem dann, wenn nicht mehr bekannt ist, welche Werte vorher in den Feldern gestanden haben. Wenn existent, hilft in solchen Fällen noch ein Backup, allerdings erweist sich die Rücksicherung eines Backups meist als recht zeitintensiv.
Deutlich einfacher lassen sich solche Probleme behandeln, wenn die Änderung eines Feldwertes direkt aufgezeichnet (oder neudeutsch: „getrackt“) wird. In früheren FileMaker-Versionen konnte so etwas z.B. unter Verwendung von Eingabedialogen realisiert werden, indem nach Klick auf die [OK]-Schaltfläche ein Script zur Aufzeichnung des Vorgangs aufgerufen wurde. Mit den neueren FileMaker-Versionen ist das Ganze dank Script-Trigger deutlich einfacher geworden. Wie es geht, zeigt dieser Artikel mit entsprechender Beispieldatei.
Werden Feldereignisse und Routinen in FileMaker-Datenbanken konsequent aufgezeichnet, ergeben sich im laufenden Betrieb handfeste Vorteile. Bei jeder Änderung wird das Ereignis in einem Protokoll aufgezeichnet, das als gesamtes Protokoll oder auch verknüpft mit einer anderen Datenbank angezeigt werden kann. So können beispielsweise alle kundenbezogenen Ereignisse in einem Layout angezeigt werden, und man erhält einen Überblick über alle Ereignisse, die im Zusammenhang mit dem aufgerufenen Kunden vorgenommen wurden. Die Tabelle für das Ereignisprotokoll enthält neben Standardangaben wie Datum, Benutzername, Tabelle oder Primärschlüssel bei Feldänderungen auch die tatsächlichen Feldwerte vor und nach der vorgenommenen Änderung. Dies ermöglicht weitere Funktionen wie beispielsweise die Wiederherstellung (unbegrenztes Undo in beliebiger Reihenfolge) von geänderten Daten – entfernt vielleicht vergleichbar wie „Visual Voicemail für Daten“ ;-)
Ein Ereignisprotokoll auch für eine bereits bestehende FileMaker-Lösung zu entwickeln, ist mit überschaubaren Mitteln realisierbar. Benötigt wird dafür zunächst eine neue Tabelle, die alle relevanten Felder für die Verwaltung von Ereignissen enthält. In der Beispieldatei trägt die Tabelle den Namen „Ereignisprotokoll“.
Jedes aufgezeichnete Ereignis entspricht einem Datensatz in dieser Tabelle, der automatische Primärschlüssel heißt _pk_Ereignis_ID. In das Schlüsselfeld _fk_Fremdschlüssel wird der Bezugsschlüssel gespeichert, auf den sich das Ereignis bezieht. Wird also beispielsweise ein Feld in einer Kundendatenbank geändert, wird dieses Feld mit dem Primärschlüssel der Kundendatenbank gefüllt. Welcher Schlüssel sich in diesem Feld befindet, wird in das Feld Fremdschlüssel geschrieben.
Für Feldänderungen befinden sich in dieser Tabelle außerdem die Felder Feldinhalt_vorher und Feldinhalt_nachher, die den Feldinhalt jeweils vor und nach der durchgeführten Änderung beinhalten.
Um ein Ereignis aufzuzeichnen, sind neben der Tabelle nun noch zwei Scripte erforderlich: Ein Script dient für den reinen Eintrag in die Tabelle Ereignisprotokoll und ist mit Script-Parameter aufzurufen, und ein weiteres Script wird für die Aufzeichnung von Feldänderungen benötigt, das per Script-Trigger am jeweiligen Feld aufgerufen wird.
Schauen wir uns zunächst das reine Eintragsscript [ts.Ereignisprotokoll] an, das folgende Script-Parameter annimmt:
Das Script selbst ist einfach strukturiert, schreibt die im Script-Parameter enthaltenen Werte zunächst in Variablen und dann in einen neuen Datensatz der Tabelle Ereignisprotokoll.
Dieses Script kann von jedem beliebigen anderen Script aufgerufen werden, das Einträge im Ereignisprotokoll vornehmen soll. In der Beispiellösung wurde außerdem die Aufzeichnung von Feldereignissen realisiert, die dieses Script ebenfalls aufruft.
Das Script ts.Feldereignis_aufzeichnen wird bei jedem Feld als Script-Trigger [BeiObjektBetreten] und [BeiObjektVerlassen] gesetzt. Es kann als optionalen Script-Parameter einen Reiter eines Registersteuerelements annehmen, falls sich das Feld in einem Bereich eines Registersteuerelementes befinden sollte. Dies ist erforderlich, damit das Script nach Anlage des Protokoll-Datensatzes in das korrekte Registersteuerelement auf dem Ziel-Layout wechseln kann.
Das Script prüft zunächst ob die Systemvariable $$feld gefüllt ist oder leer. Ist diese Systemvariable leer, hat der Benutzer ein Feld betreten, und das Script füllt die Systemvariable $$feld mit dem aktiven Feldnamen und $$feldinhalt_vorher mit dem Feldinhalt vor der Änderung. Danach wird das Script bereits verlassen, denn mehr muß das Script bei Betreten eines Feldes nicht tun.
Wenn die Systemvariable $$feld bereits gefüllt ist, hat der Benutzer möglicherweise den Feldinhalt geändert und verläßt gerade das Feld. Das Script prüft nun, ob der Feldinhalt verändert wurde und legt im Fall einer Veränderung einen Datensatz im Ereignisprotokoll an durch Aufruf des Teilscriptes ts.Ereignisprotokoll. Wenn sich das Feld in einem Registersteuerelement befindet und als Script-Parameter der Name des Reiters mitgeliefert wurde, wechselt das Script nun in den angegebenen Reiter, da nach der Eintragung sonst auf das standardmäßig angegebene Registersteuerelement gewechselt würde. Am Schluß löscht das Script wieder die Variablen $reiter, $$feld, $$feldinhalt_vorher und $$feldinhalt_nachher, und das Spiel kann wieder von vorne beginnen, denn die Systemvariable $$feld ist nun wieder leer.
Im letzten Schritt müssen nun noch die gewünschten Felder mit Script-Triggern versehen werden, damit die Eintragung in das Ereignisprotokoll bei einer Feldänderung stattfinden kann. Pro Feld müssen zwei Script-Trigger eingerichtet werden, die jeweils das gleiche Script aufrufen:
Der Script-Parameter „Reiter“ ist optional und wird nur angegeben, wenn sich das Feld, wie in der Beispieldatei, in einem Registersteuerelement befindet. Dabei wird der Name des Reiters angegeben, der im Inspektor unter dem Reiter [Position] im Feld Name angegeben werden muß.
Am Ende dieses Artikels können Sie eine Beispieldatei für FileMaker 12 herunterladen, in der das Ereignisprotokoll mit Feldwertaufzeichnung realisiert wurde. Sie können diese Beispieldatei als Basis für eine eigene Datenbank verwenden oder um die Funktionen in Ihre eigene FileMaker-Lösung zu übertragen.
Scripte lassen sich einfach über die Zwischenablage von einer FileMaker-Lösung in eine andere Lösung übertragen. Öffnen Sie einfach den Dialog Scripts verwalten, markieren Sie das gewünschte Script mit der Maus und kopieren Sie das Script in die Zwischenablage per Menü [Bearbeiten – Kopieren] oder Tastenkombination [Strg/Cmd-C]. Öffnen Sie daraufhin in der Ziel-Lösung den gleichen Dialog und fügen das zuvor kopierte Script einfach per Menübefehl [Bearbeiten – Einfügen] wieder ein.
Tabellen können auf mehrere Arten in eine bestehende Lösung eingefügt werden. Der einfachste Weg ist der Import der Tabelle über die Schaltfläche [Importieren…] im Dialog Datenbank verwalten. In einem nachfolgenden Dialog können dann alle Tabellen ausgewählt werden, die aus der Quell-Lösung importiert werden sollen. Diese Methode eignet sich also besonders, wenn mehrere Tabellen gleichzeitig importiert werden sollen. Soll nur eine Tabelle importiert werden, kann dies wie ein Script auch über die Zwischenablage erfolgen. Soll eine Tabelle samt Daten importiert werden, kann dies mit dem Befehl [Ablage/Datei > Datensätze importieren > Datei] erfolgen. Im Import-Dialog muß dann als Zieltabelle Neue Tabelle angegeben werden.
Wertelisten können einfach über die Zwischenablage von einer FileMaker-Lösung in eine andere Lösung importiert werden. Öffnen Sie einfach den Dialog unter [Ablage/Datei > Verwalten > Wertelisten], markieren Sie die gewünschte Werteliste mit der Maus und kopieren Sie die Werteliste in die Zwischenablage per Menü [Bearbeiten – Kopieren] oder Tastenkombination [Strg/Cmd-C]. Öffnen Sie daraufhin in der Ziel-Lösung den gleichen Dialog und fügen die zuvor kopierte Werteliste per Menübefehl [Bearbeiten – Einfügen] wieder ein.
Klicken Sie im Dialog [Ablage/Datei > Verwalten > Eigene Funktionen…] auf die Schaltfläche [Importieren] und wählen daraufhin die Beispieldatei aus. Wählen Sie im nachfolgenden Dialog die gewünschten eigenen Funktionen aus und bestätigen den Dialog. Bitte beachten Sie, daß diese Funktion nur in FileMaker Pro Advanced, nicht jedoch in FileMaker Pro zur Verfügung steht.
München/Unterschleißheim – 18. Dezember 2014: FileMaker-Software hat die Durchführung unabhängiger Arbeitsschutz-Inspektionen für nahezu 1.000 Bekleidungsfabriken in Bangladesch unterstützt. Das Projekt konnte in nur sechs Monaten abgeschlossen werden. Dank einer individuellen FileMaker-Lösung für iOS – in nur drei Wochen auf die Beine gestellt – wurde die erforderliche Zeit für das Reporting…
Haben Sie die Überschrift zweimal lesen müssen? Aber Sie haben richtig gelesen: Wer bis zum 20. Dezember 2012 eine Lizenz von FileMaker Pro 12 oder FileMaker Pro 12 Advanced kauft, erhält eine weitere Lizenz des gleichen Produkts kostenlos dazu. Das Angebot gilt bei Kauf einer entsprechenden Lizenz im FileMaker Webstore…
Rick Kalmann spricht über die Zukunft von FileMaker; Verleihung des FileMaker Magazin-Awards 2013 Pressemeldung - München/Unterschleißheim, 12.09.2013. Die FileMaker Konferenz 2013 findet vom 17.- 19. Oktober in Salzburg im Hotel Crowne Plaza statt. Die Veranstaltung richtet sich an Entwickler Anwender, IT-Fachleute und Entscheidungsträger aus Wirtschaft, Bildung und Verwaltung. Das nunmehr vierte vom FileMaker-Verein organisierte Zusammentreffen bietet…
Hinzufügen von {{itemName}} zum Warenkorb
Hinzugefügt {{EinkaufsName}} zum Warenkorb
Super Sache, hat uns sehr weitergeholfen. Vielen Dank für das Ganze!