Foxpro had an embedded db engine and so SQL commands could be used directly in the language for fetching data, which made it fantastic for CRUD database apps, which is what nearly all applications were back in those days. The 'tables' we're just dos files that could sit on a network drive to make the application multi-user. I think there was some limitation with the SQL, e.g. no outer joins, but it was still very handy.
MS continued to support foxpro somewhat into the .net era but then it fell to the wayside. When Linq arrived for c# it made me smile because it harks back to FoxPros embedded SQL, although of course Linq represents a _lot_ more than just embedded queries.
It was flexible too - my all-time favourite application of FoxPro is Island ECN, one of the first big Alternative Trading Systems and a direct ancestor to NASDAQs current INET platform.
Nice! Reading that code brings back memories... 1990 (around) I did a lot of work in dBase & Clipper & fox pro; it was easy to work with and, because in the Netherlands it was not that popular, I could get excellent job as 16-17 year old for the summer, working on admin systems for factories that used dbase & clipper.
I remember porting some of those systems to Java half a decade later and asking myself if this was a good direction; Java looked so... crude at the time compared to these technologies.
At least two major doctor/hospital softwares in my country still use FoxPro. But new features piled on top of decades old code base make it pain in the ass to use. (i.e. online communication with health insurance company halts the main program and launches a communication program every now and then)
C # creator Anders Hejlsberg made a statement a few years after the .net platform came into being, recognizing that data was very important and admitting that they were developing linq.
It would be interesting to get that statement, because .NET original plan was to be what WinRT is.
A improvement over the COM runtime with better tooling, but then they pivoted the idea with J++, and had to reboot it with .NET for the reasons we all know.
It was relatively rare to see SQL in idiomatic FoxPro of old, and more typical to work directly with indices, or use SCAN .. ENDSCAN. That was partly what made it so fast.
2.0 was the first version that changed it, to some extent, because it included the Rushmore query optimizer, which was actually pretty good. But veteran developers didn't trust it much even so.
MS continued to support foxpro somewhat into the .net era but then it fell to the wayside. When Linq arrived for c# it made me smile because it harks back to FoxPros embedded SQL, although of course Linq represents a _lot_ more than just embedded queries.