Hi Kev,
>The way I view it is that .Net is more scalable due to the fact that classes represent the data, that, IMO is a huge strength, although it's only my opinion and won't apply to everyone - which I guess is why Fox is preferrable to some and .Net is preferrable to others, depends what app you are developing.

It is my belief, that the fact that data is managed in classes makes .Net
less scalable if the scale is data size.
Serving up hierarchical data in an object model is easier to "visualize" and
perhaps (my personal opinion) more adequate for the typical "business object"
scenarios (customers/orders/items with less than 1000 rows in the lowest step).
Perhaps the fact that some frameworks use an object based approach
(scatter/gather) points into this direction as well.

But I cannot believe that the relatively simple structure of defined memory offsets
(easy to map from and to files) will have less efficieny when used with large amounts of data.
(at least compared to an object based scheme). The speed of VFP comes IMO largely
from the "rectangular" approach in conjunction with a very agressive caching scheme
for indices (including Rushmore in this broad definition...)

The setup overhead of using a table/view/cursor should be constant,
variations are to be expected on caching strategies (with and without indexes)
and perhaps the number of fields.
But there will be no increase in "object generation" for large tables,
since in VFP there are no datarows to be created.
One other point:

Since there are no indices in .Net (in the way we are used to use),
there probably will be some ugly way (another personal opinion <g>)
to reach n log n access functionality in .Net - something more akin
to record based operations in xbase manner than compared to the ease
of Rushmore. Probably workable, but still a wart.


my 0.02 EUR

thomas