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?