Neuigkeiten
FoxSQL ist eine TCP/IP-SQL-Verbindung für Daten aus AccountView und Visual FoxPro. C#-Anwendungen arbeiten mit vertrauten Datenbankkonzepten, während die eigentliche FoxPro-Engine weiterhin ihre bewährte Aufgabe übernimmt. Niemand muss DBF-Dateien bei Kerzenschein entschlüsseln.
Am Anfang stand eine einfache, aber gewagte Frage: Können wir den Zugriff auf AccountView-Daten aus C# wie eine gewöhnliche Datenbankverbindung gestalten? Nicht „CSV exportieren und hoffen“. Nicht „noch einen allgemeinen Provider installieren und so tun, als wäre 1998 ein guter Dauerzustand“. Sondern eine echte Client-API: Verbindung öffnen, SQL senden, Parameter binden, Zeilen empfangen, große Ergebnismengen seitenweise durchlaufen und Diagnosedaten prüfen, wenn der Rechner ins Schwitzen gerät.
Diese Frage ist relevant, weil viele Unternehmen wertvolle FoxPro-Daten besitzen, mit denen der Betrieb weiterhin gut läuft. Die umgebende Software ist jedoch längst bei Web-Dashboards, mobilen Oberflächen, APIs, Diensten und Warteschlangen angekommen — ebenso wie die Entwickler, die nervös werden, wenn eine produktive Integration von einem verbundenen Netzlaufwerk und gutem Zureden abhängt.
Die erste Entscheidung war zugleich die wichtigste: FoxSQL versucht nicht, ein neues FoxPro zu werden. Es implementiert weder DBF, CDX und FPT noch Sperren, Pufferung oder die vielen kleinen Regeln innerhalb von AccountView neu. Stattdessen bleibt Visual FoxPro im Ausführungspfad. FoxSQL liefert die moderne Verbindung; FoxPro bleibt für das Datenverhalten verantwortlich. Das ist weniger spektakulär als eine neue Datenbank-Engine, birgt aber ein deutlich geringeres Risiko, jemandem den Buchhaltungstag zu ruinieren.
FoxSqlConnection, FoxSqlCommand, FoxSqlDataAdapter und FoxSqlCursor. So fühlt sich die Arbeit wie Datenbankentwicklung an und nicht wie eine archäologische Ausgrabung.Die Architektur ist bewusst pragmatisch: Eine C#-Anwendung spricht FoxSQL.Client an. Der Client öffnet eine TCP-Verbindung aus einem Verbindungspool zu FoxSQL.Service. Der Dienst serialisiert die Zugriffe auf die Fox-Laufzeitumgebung und führt den freigegebenen SQL-Verarbeitungspfad aus. Visual FoxPro bleibt die Engine für komplexe Abfragen und Datenänderungen. C++ übernimmt die hardwarenahe Windows- und FoxPro-Anbindung, denn 32-Bit-COM wird nicht allein dadurch elegant, dass man freundlich darum bittet.
C# app -> FoxSQL.Client -> pooled TCP connection -> FoxSQL.Service -> Visual FoxPro / AccountView data -> binary rowset frame back to C#Diese Trennung ist wesentlich. C# verändert DBF-/CDX-/FPT-Dateien niemals direkt. Die Verbindung vermeidet einen COM-Aufruf pro Zeile. Aufwendige FoxPro-Arbeit wird gemessen. Schreibzugriffe müssen in der Konfiguration ausdrücklich freigegeben werden. Und wenn eine Ansicht Seite 17 einer großen sortierten Ergebnismenge benötigt, kann FoxSQL einen Ausschnitt der Zeilen abrufen, statt zum siebzehnten Mal alles neu aufzubauen.
Der Weg war nicht geradlinig — meist ein gutes Zeichen dafür, dass man es mit echter Software zu tun hat. Zunächst stand eine Machbarkeitsuntersuchung an: FoxPro und AccountView mussten erreichbar sein, Daten sollten ohne OLE DB oder ODBC übertragen werden können, und der Dienst musste eine Laufzeitinstanz dauerhaft vorhalten, statt für jede Anweisung einen teuren Start durchzuführen.
Danach wuchs das Projekt schrittweise: zuerst Protokoll und C#-Clientschnittstelle, dann Ergebnisserialisierung, SQL-Klassifizierung und Parameterbindung, anschließend seitenweiser Abruf, Regeln für Datenänderungen, schnelle RECNO-basierte Aktualisierungs- und Löschpfade, Invalidierung des Ergebniscaches, Verbindungspooling, Bereinigung des gemeinsam genutzten FoxPro-Zustands, Pufferwiederverwendung, blockweises Lesen von DBF-Ergebnissen und schließlich explizite serverseitige Cursor. Also die interessante Art technischer Grundlagenarbeit, bei der jede Millisekunde einen Namen hat.
Die Messungen prägten den Entwurf. Ein naives Update mit WHERE RECNO() = ... kann unbeabsichtigt die gesamte Tabelle durchlaufen, wenn es den falschen Verarbeitungspfad nimmt. Deshalb erhielt FoxSQL eigene Datensatznummernpfade, die nativ zum Datensatz positionieren, wenn die Anwendung ihn bereits kennt. Das ist keine voreilige Optimierung: Man erkennt ein Schlagloch, markiert es und baut eine kleine Brücke darüber.
Als Nächstes soll FoxSQL auch außerhalb von .NET-Anwendungen nutzbar werden. Der C#-Client ist die erste vollwertige Schnittstelle, weil er einen echten Datenbankzugriff bietet: Verbindungszeichenketten, Befehle, Parameter, Adapter, Reader, Cursor und vorhersehbare Fehlerbehandlung. Doch die Verbindung soll nicht auf C#-Desktopanwendungen oder die Kommunikation zwischen Diensten beschränkt bleiben.
Geplant ist ein direkter JSON-Antwortmodus. Aufrufer sollen Daten bei FoxSQL anfordern und sauberes JSON erhalten können, ohne zunächst alles in eine DataTable umzuwandeln. Das ermöglicht schlanke Integrationen, Verwaltungsoberflächen, Endpunkte für mobile Anwendungen und Webwerkzeuge, für die JSON das natürliche Austauschformat ist. Der binäre Rowset-Pfad kann für anspruchsvolle Clients schnell bleiben; JSON wird der einfache Zugang für andere Anwendungen.
Damit können auch PHP-Websites vollwertige Clients werden. Eine PHP-Website soll FoxSQL aufrufen, eine freigegebene Abfrage ausführen, Parameter binden und aktuelle AccountView-Daten auf einer Seite darstellen können — ohne DBF-Dateien anzufassen, ODBC-Treiber zu installieren oder dem Webserver alte Desktop-Rituale beizubringen. Die Website fragt Daten an, FoxSQL kümmert sich um die FoxPro-Umgebung, und AccountView bleibt die maßgebliche Datenquelle.
Damit wird FoxSQL zu dem, worauf sein Name von Anfang an zielte: einer echten SQL-Serverschicht über FoxPro und AccountView. Nicht Microsoft SQL Server und auch keine nur oberflächlich nach Datenbank aussehende Lösung, sondern ein echter Serverprozess mit Protokoll, Authentifizierung, Abfrageprüfung, Ausführungsregeln, Diagnose, Ergebnisformaten und verschiedenen Clienttypen. Bestehende Daten, moderner Zugriff und sinnvolle Grenzen. Und weniger nächtliche Rituale mit Treiberinstallationen.
FoxSQL ist interessant, weil es nicht so tut, als würden alte Daten durch moderne Schlagwörter modern. Es respektiert die bewährte Engine, kapselt riskante Bereiche und bietet modernen Anwendungen einen kontrollierten Zugang: Verbindungspools, parametrisierte Befehle, Rowsets, Diagnosedaten, seitenweisen Abruf, Cursor, auf JSON vorbereitete Integrationspfade, Installationswerkzeuge und einen Windows-Dienst, dessen Produktionsreife sich prüfen lässt, statt sie nur zu erhoffen.
Das Ergebnis ist eine Verbindung mit genau der richtigen Portion Eigenwilligkeit: FoxPro bleibt für seine Aufgaben zuständig, C# erhält eine echte Datenbank-API, PHP bekommt einen klaren Zugang zu aktuellen Geschäftsdaten, und ODBC muss nicht länger für jede langsame Abfrage im Unternehmen den Kopf hinhalten.
Mehr
Wie aus einem testbaren Swift-Paket ein datenschutzorientierter Belegscanner für iPhone, iPad und macOS wurde — mit OCR, Core ML, CloudKit-Synchronisierung, Exporten, Trainingswerkzeugen, Produktionsprüfungen und der mühsam gewonnenen Erkenntnis, was Kassenbons Software tatsächlich abverlangen.
Hamlet gehört zu den wichtigsten Entwicklungen auf unserer aktuellen Produktroadmap: ein nativer Editor für formatierten Text, Seitenlayout und datenbankgestützte Dokumenterstellung, speziell für 4D. Das Ziel ist anspruchsvoll, aber klar: 4D-Entwickler sollen einen leistungsfähigen Dokumenteditor erhalten, der direkt in einem 4D-Formular arbeitet, echte Datenbankdaten nutzt und professionelle Rechnungen, Berichte, Briefe, Vorlagen und Publikationen erzeugt.
Wir haben 4D Agenda grundlegend modernisiert und das klassische Plugin aus den frühen 2000er-Jahren in eine saubere, stabile und moderne macOS-Codebasis überführt. Der ursprüngliche Code stammt etwa aus dem Jahr 2003 und hatte viele Jahre zuverlässig gearbeitet, brachte aber alte Zeichenroutinen, überholte Plattformzweige, klassische Mac-Annahmen und umfangreichen historischen Kompatibilitätscode mit.
