Hi John,

Think again: Mike Pizzo (http://blogs.msdn.com/data/archive/2006/12/05/data-access-api-of-the-day-part-i.aspx) has been around for 15 years designing data access at MS, which puts it back to the release of VFP. And in fact, the history of ado (related in more than one place) is that when vfp was released in 94, the data team walked over to another building at MS and started working on ado.

The reason that doing SQL over objects is useful in statically-typed .NET languages is because of the "impedance mismatch" that I referred to in my post. In VFP the data is always there, whether it's a table, a view, or a cursoradapter. When one has the cursor available, selecting against the cursor is what makes sense. It's only when what is in the object and what is in the cursor are different, or data isn't being held in a cursor, that it makes sense to shoehorn sql into querying objects. And why would data be held in objects rather than, say, a temporary cursor? Because of that impedance mismatch again. Where in VFP we would CREATE CURSOR and then could work with it, in a statically typed language this becomes a mess, both in creation and in usage.

Linq to Objects is, as I see is, a solution to a problem that should never have occurred. IOW, it's a creative solution to the wrong problem. The VFP Compiler for .Net is a solution to the real problem: it cures the impedance mismatch, while providing seamless access to the rich .Net ecology.

Hank

>>Hi Mike,
>>
>>indeed. If you read the MSDN overview on the Entity Framework, it talks about solving the "impedance mismatch" (their term) between data and objects. And the MVC framework is yet another attempt at the same thing. Just as Linq was. Just as ADO.Net was. VFP has no impedance mismatch, of course.
>>
>
>LinQ is nothing like VFP's select..... that was only against tables whereas linq can operate against many broader forms. I would also bet that the developers of LinQ never heard of foxpro.