>Here's a question for you: as local processing becomes the latest must-have innovation, how many of those who scoffed at the Fox implementation that has existed for over 20 years, are current MS MVPs? ;-) Perhaps they'll be equally vocal in explaining why it's suddenly a marvelous idea when it was a worthless Foxism for the past few years.

To be fair, the fox implementation has some corners I'd like to be implemented differently: for instance to be able to hint the drive where spilling should happen, so that in between large SQL sessions you could switch "tempdisk" or put some cursors on different disks. Thinking on from there I'm guessing that the pure memory idea for datasets stems from connected&stateful server scenarios, where exceeded temp quota, left over temp files and so on could be more troublesome than on a WS. For a server process leaving "autospanning" to the swap file eliminates a couple of potential worry areas. And it is that area, where MS is in danger of loosing the battle [besides the mobile OS front]. So cursors were shafted...

Having table capability also led to direct coupling of GUI and backend and monolithic approaches - while most of todays apps are overarchitechted, this is often less of a mistake than oversimplifiying. Made a great straw man argument as well.

But: If I view my work, 30% of it is helped by the tight data integration immensly, while another 45% could have been done in almost any modern language/fwk, 25% sits in between, gaining from interpreter turnaround, but could have been done in python or similar ones. And while most ***customer*** apps would benefit from local data storage possibility, I only remember 3 of mine where local munging ability was the conditio sine qua non.

Differencing between local lookup install *and* central multiuser data storage is a pattern not used often even in vfp apps. All to often lookup data are clumped with the updatable data "because it is data".... We as fox devs sometimes delivered a clear proof that such designs are not always necessary :-(
I remember loosing 3 arguments in a row as it was deemed to expensive to add and test local lookup storage for a big insurance user base - then somehow the size of the needed app's grew by an amount similar to that of the lookup tables, and all apps were deployed locally ;-)) I still wonder if or when the manager realized that the reason for the speed increases he praised was my not following his orders for lookup tables...