>>Write a very simple query and then display out the fields (make sure you've got a number of different types - date/time, ints, etc) using DataSets, Referencing and correctly casting fields to the correct type is tedious and error prone with DataTables, if you're not using any other types of wrappers to project them into a typed object. Then do the same thing using EF. It should be easy to see how much easier it is to EF as compared to DataSets/DataTables.
>
>Yes, I'm thinking that I will have to cook up a Dataset demo for them to show them the difference.

You might also want to just dummy up project with an EDM built from their data with the wizard. Show them the navigation properties building in a lot of the parent child and lookup stuff.

>>
>>Just being able to project the results into a type is huge. If you then need to run subqueries on the results, EF via LINQ makes things MUCH simpler. And if you really want to use stored procs or direct SQL, you can (there isn't anything stopping you from doing that in EF).
>
>Yep!
>
>>I've used gone the standard DA route - direct to DataSets/DataTables, then to a simple object wrapper on top of a row in a DataTable, LINQ to SQL, and now EF. While LINQ to SQL is easier to get running "out of the box", the latest version of EF has a lot of nice features (and isn't that much more complex to get up and running with). I wouldn't have switched if I thought the new way was worse than the old way.
>>
>>Do you only use SEEK and LOCATE in your apps? Or are you using SQL as well? Did they complain about switching to SQL because it was "so hard to learn"? Would they want to give it up (assuming they are using it)? I feel the same way about LINQ, and L2S/EF.
>
>Mostly, we use SQL in our VFP apps. In fact, we use a lot of SQL to create cursors to create add'l cursors and the report them out. But, it took them the longest time to go from do while not eof() to Scans. I think Scans were like FoxPro 1.0 for DOS.