Armin Egginger steuerte als Wunschthema einen technischen Deep-Dive bei, der aus einem realen Notfall entstanden ist: eine FileMaker-Datei, die sich mit Bordmitteln nicht mehr retten ließ. Am Ende steht ein Werkzeug, das die .fmp12-Datei direkt binär ausliest – ganz ohne FileMaker.

Der Ausgangsfall

Ein Kunde hatte eine Datei, die beim Öffnen des Datenbank-Designdialogs reproduzierbar abstürzte, sobald bestimmte Kalkulationsfelder betroffen waren. Sämtliche Wiederherstellungsprozesse blieben wirkungslos. Ein Verhalten, das man nicht nachvollziehen kann – und bei dem die Frage im Raum steht, was man mit einer solchen Datei überhaupt noch anfangen soll.

Weg 1: FileMaker 2026 Upgrade Tool

Mit FileMaker 2026 gibt es die neue Möglichkeit, aus einem SaXML-Export wieder eine komplette Datenbank zu generieren – mit neuen UUIDs, neuen Strukturen und neu geschriebenen Objekten, die nicht von anderen kopiert wurden. Armin hat sich dafür eine grafische Oberfläche für das Upgrade Tool gebaut.

Der erste Versuch scheiterte an einer Fehlerlawine. Die Lehre daraus – und ein Wartungstipp für alle:

Vor jedem Eingriff die UUIDs neu generieren lassen.

Preprocessing des XML

Auch nach dem UUID-Lauf blieb das XML defekt. Armin schrieb daraufhin einen eigenen Vorverarbeitungsschritt:

  • Zeichenbereinigung: Sonderzeichen und ungültige Zeichen, die das XML unverarbeitbar machen, werden entfernt.
  • Baumumbau: Viele Fehler stecken in bestimmten Layout-Objekten. Deshalb werden die Kataloge im XML-Baum so umsortiert, dass die fehlerträchtigen Bereiche weiter unten liegen – so werden die oberen Kataloge zumindest vollständig geschrieben.

Damit ließ sich schließlich eine neue Datenbank erzeugen.

Ernüchternder Zwischenstand

Doch das Ergebnis war nicht vollständig. Armin baute sich ein Compare-XML-Werkzeug, das ein neues SaXML der wiederhergestellten Datei gegen das Original stellt und einen Report erzeugt. Das Ergebnis:

  • Sieben Summary-Felder fehlten komplett – obwohl sie im XML enthalten waren. Ein Muster war nicht erkennbar; betroffen waren ausschließlich Summary-Felder.
  • Custom Functions ohne Kalkulation: Objekt, Name und Parameter waren angelegt, die Berechnung intern aber leer. Nicht etwa fehlerhaft – schlicht nichts drin.
  • Defekte Icons: Rund 800 Icons waren im XML durchgehend defekt, auch die von FileMaker mitgelieferten.

Die Nacharbeit lief zu Fuß: fehlende Kalkulationen aus dem CDATA-Bereich als reinen Text übernehmen, fehlende Felder nachbauen und neu verknüpfen. Für die Zuordnung nutzte er weiterhin CrossCheck. Ein Nebeneffekt: Nachträglich angelegte Felder bekommen neue IDs und rutschen in der ID-Historie nach unten.

Sein Fazit zum Upgrade Tool: pauschal einsetzbar, Nacharbeit eventuell nötig. Bei einer sauberen Ausgangsdatei lief die Neuerzeugung ohne jeden Handgriff durch. Die defekten Dateien des Kunden konnte er am Ende alle reparieren und komplett neu aufsetzen. Wichtig zu wissen: Nach der Neuerzeugung müssen alle Dateien neu authentifiziert werden, weil der Authentifizierungsschlüssel nicht mehr vorhanden ist – FileMaker fragt das beim ersten Öffnen ab.

Die Befunde hat Armin bereits zu Claris ins ETS gemeldet. Die Schwierigkeit dabei: Ein reproduzierbarer Testfall lässt sich nicht konstruieren – mit einer frisch angelegten Datenbank funktioniert alles sauber. Die Meldung müsste daher vom Eigentümer der Originaldatei kommen.

Weg 2: Das Recovery Toolkit

Nach diesen Erfahrungen zog Armin eine grundsätzliche Konsequenz: “Ich kämpfe die ganze Zeit mit XML-Problemen – mit der Größe, mit der Verarbeitungsgeschwindigkeit, damit dass es nicht geöffnet werden kann.”

Die Lösung lag in der eigenen Vergangenheit. Damals hatte er einen externen Entwickler beauftragt, für CrossCheck Daten direkt aus dem Binärformat zu lesen – dem Verfahren, das man von FMDiff kennt, dem Werkzeug von Winfried Huslik, das nicht mehr weiterentwickelt wird. Mit AI-Hilfe ließ sich der Ansatz von damals nun weiterführen.

Wichtig für das Verständnis: Es handelt sich nicht um Reverse Engineering. Armin ging direkt an das Binärformat. Sein Vorteil dabei: Aus zwei Jahrzehnten eigener Entwicklung an CrossCheck lagen bereits vollständige Referenztabellen vor – etwa die Nummern aller Skriptbefehle samt ihrer Parameterbedeutung. Diese Vorarbeit konnte er der AI mitgeben, sodass sie einordnen konnte, welcher Inhalt zu welchem Befehl gehört.

Das daraus entstandene Recovery Toolkit beherrscht zwei Prozesse.

Schema-Extraktion nach JSON

In der Live-Demo lief eine 20,5 GB große FileMaker-Datei durch. Das Ergebnis: ein Schema von 14,7 MB im JSON-Format – mit 1.713 Table Occurrences und 133 Basistabellen, dazu Felder, Layouts, Skripte, Wertelisten, Accounts und Beziehungen. Bei den Layout-Objekten reicht die Information bis in die Detailtiefe einzelner Positionen.

Bewusst JSON statt XML: klein, schnell verarbeitbar und für AI-Modelle deutlich leichter zu handhaben Technisch arbeitet das Tool mit Streaming statt Einlesen – die 20,5 GB passen nicht in den Speicher. Trifft der Stream auf einen Fehler, bricht er ab und meldet das.

Datenextraktion nach CSV

Im zweiten Schritt schreibt das Tool die Inhalte aller Tabellen als CSV-Dateien heraus – direkt aus dem Binär-Blob, ohne den Umweg über die FileMaker-Engine. Das ist um Größenordnungen schneller als ein regulärer Export.

Damit ergibt sich ein konkreter Anwendungsfall: Wer keine FileMaker-Lizenz mehr hat, aber noch eine FileMaker-Datei und die Daten braucht, kann sie so retten. Und es entfällt der Save-a-Copy-as-XML-Prozess, der Benutzer aussperrt, Tabellen sperrt und den Server praktisch zum Stillstand bringt – ein Backup als Clone ist dagegen schnell gezogen.

Der Haken

Für die Extraktion wird kein Passwort benötigt. Solange eine Datei nicht mit Encryption at Rest verschlüsselt ist, ist sie – in Armins Worten – “offen wie ein Scheunentor”. Man muss nichts umgehen, man liest einfach.

Das ist einerseits der Grund, warum eine Veröffentlichung als Tool schwierig ist. Andererseits ist es keine neue Erkenntnis: Tools, die lokal auf Dateien zugreifen und den Passwortabschnitt austauschen, gibt es seit jeher. Armin verwies dazu auf einen aktuellen Blogpost von David Hamann über das Einschleusen von Accounts in FMP12-Dateien über die Patch-File-Funktion des Upgrade Tools.

Stand der Dinge

Das Auslesen des Binärformats ist noch nicht abgeschlossen. Der Fertigstellungsgrad liegt derzeit bei ca. 70%. Aufgrund von Unstimmigkeiten bei der korrekten Interpretation des Formats müssen immer wieder Sonderfälle aufwändig untersucht werden.

Fazit

Was hier in kurzer Zeit vorgeführt wurde, steckt voller Wochen und Monate an Testen, Mustersuche und Nachbau. Das Ergebnis ist eine echte letzte Verteidigungslinie: Selbst bei katastrophaler Dateikorruption lassen sich Schema und Rohdaten in universell nutzbaren Formaten retten – und in eine neue, saubere Datei importieren. Datenrettung als Dienstleistung ist damit ein realistisches Geschäftsmodell.

Weitere Infos:

CrossSolutions – Kontakt zu Armin und zu CrossCheck
https://www.cross-solutions.de

Portage Bay Blog – Can FileMaker 2026 Rebuild a File Clean? Testing GenerateDBFile
https://www.portagebay.com/blog/can-filemaker-2026-rebuild-a-file-clean-testing-generatedbfile/

FMDiff – Werkzeug von Winfried Huslik zum Auslesen des FileMaker-Binärformats, historischer Ausgangspunkt der Binär-Extraktion
https://fmdiff.com/