alt Hacker NewsWe run 500 KLOC of FoxPro at my company, daily. It is the engine that fuels a $500M business.
I hate that it's the hand I'm dealt, but aside from AI rewrites (underway), there's no good answer. It's complicated by our reliance on DBFs.
I welcome efforts like foxscript and anything else in this space. There are still a significant number of FoxPro apps out there and no one has a good answer. If you are struggling in this space, leave a comment here. I'll reach out to you. Strength in numbers...
Replies
DBFs tend to be the easy part, in my experience in a similar company (not as much revenue.) The spec is simple enough that one can write a reader/writer in an afternoon, even before AI.
My biggest challenge is the speed at which calculation heavy business logic can operate in FP, even on network shares, as long as they're optimized for IOPs not bandwidth. Trying to adapt similar data access patterns to a networked RDBMS will kill you with round trip and connection overhead. Converting that logic to set-based operations or stored procedures means altering logic and all the risks that entails.
Would you trust foxscript? I'm curious if this is just a wide-net data exfil attempt.
Hi Neat! you mentioned you guys are already on a rewrite path. That is the proper way forward and I recommend gathering as much information about the product and edge cases as possible. Document every business rule, every product decision. Handwaving aside, audit the Foxscript source code, clone it to a virtual machine or container. Any issue you face, feel free to post an issue on Github as I would love a few edge cases on the wild. As the Foxscript runtime relies on 64 bit offsets for the DBF/Memo, once a DBF (past the 2GB) is opened they can't be migrated back to old VFP9, so I recommend to test this carefully on an airgaped setup with tests DBF.