Kevin

I guess my concern is that an inexplicably complex SQL query is being used to "prove" that C# is quicker than VFP- not necessarily by you, but a certain other immediately seized it as a definitive "proof".

I can't help but question why that query is used. There has to be a reason- it seems to be designed to pull full customer details, not just a single field, and it has joins of uncertain purpose. In addition, it sort of looks as if SELECT * would achieve the same result as including the other 2 fields- isn't it all coming from the client table?

Without explanation, a cynic might regard the example as a "trick shot"- a weird combination that, for some reason, demonstrates a particular point, but which has little bearing in real life. Not being critical, and I fully understand that the real purpose of that query may not be something you want to expound upon here, but you need to understand why some eyebrows are currently raised.

For myself: we experimented early on with unavoidably large resultsets in C#, including mimicking USE AGAIN to allow multiple selected records in large lookups. dotNET was frankly unusable and will remain so until it learns to span large resultsets between disk and memory, something we've taken for granted in FP since 1990.

However: with small resultsets like yours, dotNET's memory fixation may well prove an advantage if VFP is already spanning to disk, which it may be depending on your setup. For those who can always keep resultsets small and whose infrastructure causes VFP to start spanning with relatively small resultsets, that may be relevant.

Regards

j.R