Hi Johan,

Thanks for this great clarification on Xsharp vs VFP and all the stuff you provided lately.

As a user of both fox, python and other interpreter-based tools, I always have been somewhat reluctant to move my stuff - ie relatively large data-centric apps - onto anything like a compiler. Back in the years I never looked into clipper and followers. The sheer speed and efficiency of fox and later vfp in data-related matters would be an answer on any optimization issues... But that may change especially in view of the way dotnet is evolving and fox not moving, stuck single-threaded in its ageing 32bits world.

Most of the die-hard VFPers have used the rushmore-augmented cursor-and-cdx-es based SQL extensively over the years.
That includes download stuff from powerfull server engines and local massaging of temporary-RAM-based cursors (they are in VFP). As far as I am concerned, I have even moved part of my algo-s into SQL. It means costly interpreters WHILE / FOR loops get replaced by AD HOC SQL operations on temporary ad hoc cursor. Replacing loops with cursors... Yes that can be quite efficient when you cannot resort to processor-level operations:-)

Summed up in a sentence : the vfp sql literally shined with very little supervision from the developers themselves (no low level structures to map and handle). And that may be a reason, among a few others, why some of us here sticked for so long to VFP. That was clearly mine. And still is by the way:-)

I understand that at the current junction, there was no such thing in VO and now and in Xsharp. Should we move our good old fox apps to Xsharp i-e within the large dotnet ecosystem, what would be the way to get sheer speed when managing large sets of data? say get fast operations onto table structures in the 10 to 100k ie without resorting to low-level operations and/or data structures of course.

I imagine that could be:
- use something like an "in memory sqlite engine" (a typical solution for C-based python),
- some linq-related technology...

Hope my post was clear enough. Language design is not my thing!

Daniel