Writing to FoxPro tables that are still open
FoxPro still runs real operations, and the application sits open on every desk from eight in the morning. Moving that history anywhere normally means closing the business for a weekend.
Instead I wrote a DBF engine in Python with no dependencies that speaks FoxPro’s own locking protocol: it takes the exact byte range of the row it is touching, never the file, and writes each record in a single pass so no concurrent reader ever sees half a row. The legacy application keeps working and never notices. On top of it runs a FastAPI service that does two different things: it migrates by date range as a followable job, and it answers live queries without migrating anything — which is how reception resolves a patient while every cash desk is writing to that same file.
The data never left the building. It lived on the local network, tied to the application that wrote it, and the only way out was an Excel report.
The same data is multiplatform: dashboards that refresh themselves, a patient resolved from a tablet at the desk, devices that talk to each other, and analysis nobody could even propose before.
