>//
>var q =
> from c in db.Customers
> where c.city == 'London'
> Select(c => c.CompanyName);
>
>ObjectDumper.WriteLine(q)
>//
>"Q" would hold a list of all the company names in London.
>
>there's no definition of the data type of the variable it comes from the result of the select statement.

>>>>Well, actually, there is no implicit definition, but q is still strongly typed. The difference is that its type is inferred from the assignment.

I kind of meant what you are saying or at least tried it, anyway, that's exactly what it its q value is 'inferred'.

>>>In this case, it would be an array or ArrayList.
not sure what it is yet, it might be, q is processed by the ObjectDumper, a piece of code written for generating an output like the old DOS SQL text output.

>>>But there is something pretty different here, and this is that the equivalent of a Visual FoxPro cursor is not a relational thing anymore, but an object, and you can even get a hierarchical object (a list of lists), inheriting from a previously defined class or (new in C# 3), defined in place as an anonymous type (something very handy).

Yes, but for those of us who use oop to see their data shouldn't be a problem ;)

>>>There are more simmilarities to Delphi (a language that a guy called Anders something desinged) that to Visual FoxPro. The important thing for me is that it resolves part of the Visual FoxPro domain space pretty well (or at least it seems by now).

I know nothing about Delphi, but the code I just saw in a second session a few moments ago couldn't be more similar to the code I write in foxpro, I mean, they are doing something like this (roughly presented):

Open transaction
query data
massage data in ways of a business object (setting optimistic or pesimistic updates)
submit changes
end transaction

This looks familiar, doesn't it?