Gerry,
I wholeheartedly agree on EF and Linq (my blog itself is concentrated around Linq). What I wanted to say is, he said that he had complicated logic in his application. I (maybe wrongly) presumed he is not comfortable with Linq and EF yet. Or even if he is I still thing it is not something that one could code in a night. If he has time then I completely think as you do.

PS: I would also suggest exactly what you did if I didn't see that 'complicated' word and regretted:)
Cetin

>Using EF, I think one spends less time on data access and has more time to spend on the logic; I think the logic is also simpler; e.g. little or no typed / untyped datasets or custom entities versus EF generated entities ...
>
>Including Oracle, I think there is now also a MySQL EF provider available. It only gets better.
>
>>>Bite the bullet.
>>>
>>>With VFP free tables (and only 12 of them):
>>>
>>>1) Create a new SQL server database and import the free tables using the OLE DB provider (< 1 hour).
>>>2) Generate an Entity Data Model (Entity Framework EDM) from the database using edmgen.exe in order to generate strongly typed data objects ( < 1 hour)
>>>3) Configure a new project to use the new EDM and starting coding … (using LINQ to Entities for data access)
>>>
>>>I see no advantage to the 2 stage approach.
>>>
>>>>Hi
>>>>A client has a fairly complex VFP app (I wrote it) that needs to be converted to C# in two stages:
>>>>1- convert the GUI and business logic to C#, leaving the data in VFP free tables
>>>>2- convert the VFP free tables to SQL-Server
>>>>
>>>>There are about a dozen tables involved. fewer than 100 transactions per day, but each transaction looks at every table several times, using indexing.
>>>>25000 records in the largest table..
>>>>What is the best way to access and update the VFP tables from C#, VS2008?
>>
>>In which of those hours you would implement the complex business logic he mentioned:)
>>Cetin