>LINQ is smart enough to handle the typing based on the types. The only reason it doesn't becacuse he's using a DataTable. If you query directly from the database into a LINQ query you don't have this issue.
>
>I'm not sure why you would use a DataTable as an intermediary in any case. That's going to be a specialty case.

In reality the data could come from anywhere, whether directly from the database or stored in memory as metadata. The question (I know beating a dead horse, but a good one to think about), is why the hell a developer should care ?? If it is only to keep the compile happy, it is something that the .NET team should address, because it is a PITA to choose one over another depending on particular cases. It (again) forces developers into extra steps or a certain direction of limiting options which should not be neccesary in the first place. Type casting as specified in Query1 should not be neccesary at all when handling data. Let LINQ resolve the issue at runtime and raise an error as any database would.

I would however have no problem is the compiletime checking was OPTIONAL, a thing I always wanted for VFP, but certainly a way to avoid when neccesary without sidesteps like ex,plicit casting, .NET generics or reflection.

Walter,






>
>
>+++ Rick ---
>
>
>>Kevin,
>>
>>Why should I, as a poor developper care about the datatype ?? I would like to avoid query no 1 at all costs as it is backward programming. The development tool should handle it. Now I know you all feel strongly about strict typing, but any way you cut it, either using typed datasets or not, if the field definition changes on the server you still have a problem.
>>
>>I would like to see LinQ do this totally transparent and generate an error if there is a type conflict at runtime in the case the type cannot be determined at compile time.
>>
>>Case in point is that in my applications I use 'remote views' (in .net would be typed datasets), SPs and SPTs transparently. VFP does not care where it comes from, and why the hell should this restriction exist in .NET ? To me it only adds to the frustration of the developer to deal with type casting again and again beyond any reasonable point. Sure, compile time checking is an important feature that certainly has advantages over the VFP way, but in this case (but also in late binding COM objects) it is just a PITA in many respects and hurts productivity, maintainability and readability.
>>
>>I know you mentioned ".NET generics" to overcome some of those problems, but IMO it fails to address the real issue here.
>>
>>Walter,
>>
>>
>>>your preference for Typed DataSets rules in April 2007...
>>>
>>>In LINQ to DataSets (as of today), if you query against an untyped datatable...
>>>
>>>

>>>var Query =
>>>   from rowData in dtWorkers.AsEnumerable()
>>>      where rowData.Field<string>("FirstName") == "Kevin"
>>>       || rowData.Field<decimal>("Salary") > 90000
>>> select rowData;
>>>

>>>
>>>If you query against a typed datatable...
>>>
>>>

>>>var Query =
>>>   from rowData in dtWorkers.AsEnumerable()
>>>      where rowData.FirstName == "Kevin"
>>>       || rowData.Salary > 90000
>>> select rowData;
>>>

>>>
>>>
>>>Which would you prefer?