FoxPro killed in 2007, revived as 64-bit FoxDev Studio

I worked with a physician's office in 2006, and the lead physician had cobbled together a system for patient tracking using Visual FoxPro. It was a monstrosity, and using it over a network drive gave all sorts of file locks and issues with multiple people changing the same record (usually the physician and front of house staff when checking the patient out).

I finally got the physician to switch to a proper client/server architecture using .NET WinForms and ASP.NET RPC calls. All issues went away, and I was even able to allow staff members to edit the interface to set what mattered to them most at the top of the application, by building the lab testing form in XML so they could move the X/Y coordinates to where they wanted them. It wasn't even a feature I had thought of, just a physician looking through the technology and figuring out how it worked (luckily the business and security logic were on the server, so a bad actor could only have destroyed their own local copy of the app).

My goodness, a blast from the past. Such a glorious time to be a programmer... every single business needed a database to do their simple little daily chores, the coding was insanely easy (just a bunch of CRUD process), and the difference it made to the customers was night/day... hence, you could charge thru the roof.

I wrote a simple little CRUD app in FoxPro, for the Canadian real estate appraisal market, which took about a part-time month to create, and first year, sold 300 licenses at $299 a pop.

Ahh, memories of a simpler time.

Flashback. When I was an adolescent, the dBase and Fox products were my first paid software development, and they were surprisingly accessible to even kids.

I was only supposed to help assemble computer furniture, and maybe install networked Unix and PC software, but the retired Marine my mom worked for thought I had potential. "Hey, Kid", he would say, we need to modify this dBase vehicle fleet insurance database to support more vehicles; figure it out. Here's the manuals for C database library, and Microsoft C, I'm evaluating; figure it out. We need to migrate between accounting systems; here's a sample .DBF of the target schema, here's how you generate a full dump from the legacy minicomputer, use this editor called Emacs to clean up the dump for import, once you figure out the schema mapping; figure it out. I also bought an older dBase product, and then a Fox product, for home, and figured out how to build a few fancier systems.

(Then I kept working, and there was a period when all employers either wanted me to figure out something, or were favorably surprised when I soon did, thanks to formative influences of figure-it-out mentors. Then a break to get belated formal degrees, then being surprised after that pause, when job interviews were suddenly Leetcode-like, and they didn't seem to want me to figure it out, but wanted a rehearsed ritual performance conforming to a big-corporate sanctioned set of rules, and apparently the Marine hadn't written a book to counterba […]

The low barrier to entry, high developer productivity, and

bespoke and "highly conforming to proprietary business processes" nature of resulting applications are all really cool, but man, it sucks when one of these systems outgrows the capabilities of the underlying platform.

I shudder at the though of businesses trying to access DBF files on "network drives" across the variety of shitty overlay network technologies that are the norm today. Seamless remote access to applications is the exact recipe Visual FoxPro apps fail at.

It looks cool but I wouldn't want actually work around apps built in it. It would be cool if a client/server database could be transparently shoehorned in to it.

Hey, I got to mention this recently! One of my bizarre claims to fame was writing this little tool[0] a few employers back to convert Visual FoxPro database files to PostgreSQL as part of a migration. For a while we had to run it as a cron job so that people could to data entry in an old VFP app but others could run fast reports on our web app with a postgres backend. It wasn't pretty, but it worked great and helped us get off that ancient stack.

[0]https://github.com/kstrauser/pgdbf

haha, I used this exact example in sales calls to make the case against app modernization. Sometimes, you just need the stuff to keep working, with $20-and-a-roll-of-duct-tape-level budgets.

My proposal was proxy layer sitting in between, running on something like k8s and written mostly by an LLM to provide a safe interface to queries against foxpro, with ratelimiting, query parsing, rest, whatever other business logic you want.

I am appalled at the fact it's still out there, but there is even older, more Archean stuff out there running literally the entire world :)

Please stop using AI to write it gives a headache. Just go with simple 2 line sentences you can write on your own or even dictacte it if youre lazy.