>>>>agreeing with you in tendency (less acerbic) on the other points, but
>>>>
>>>>>VFP's data handling is an anachronism when using a server based database.
>>>>
>>>>Why ? Having the backend where-specified data mirrored in equivalent tables to feed the biz objects
>>>>IMHO is more sensible than EF or other ORM frameworks (nHibernate or what do you use ?).
>>>>Especially if you are fluent in SQL, why for need 2 different ways to access data ?
>>>>Do you prefer LINQ vs. SQL, as it again puts you into a MS-controlled niche compared to SQL on nealy all backends ?
>>>>
>>>>The local cursor engine (pls separate from dbf as backend data store) is the thing keeping me with vfp -
>>>>and is the thing making me look at Lianja, as today there is no client financing a cursor cache layer
>>>>with SQLite having update automatics similar to Ado.Net or vfp-Cursoradapter,
>>>>which is what I'd create to scratch my itches.
>>>
>>>In .NET you have local tables you can manipulate. You can use LINQ on them. Not quite as easy as VFP cursors but they are functional.
>>>
>>>Again, I do my data manipulation server side if at all possible.
>>>
>>>
>>
>>PMFJI; over the weekend I read a tutorial on Entity Framework and it sound (the tutorial was not very clear on that though) that you can't use EF without LINQ. Is this correct?
>
>As far as I've seen, everything you do with EF revolves around LINQ.
>
>I was originally pretty excited about EF, but when I realized it didn't handle Stored Procedures w/o a lot of under the hood work I gave up on it. The benefit was not worth the cost since I use stored procedures a LOT.

EF does not all revolve around LINQ. Entity SQL is an alternative to LINQ to Entities. Julia Lerman devotes an early chapter to Entity SQL in her authoritative book. She does state that LINQ to Entities is what most people will use.

Doing as much as possible in SPs, good man ;-)