Yeah, I saw that.

>>Thanks, Bonnie!
>>
>>There's not a lot of "auto-magic" stuff in VFP. A skilled VFP developer has to understand how things work at the detail level. Not necessarily so in .NET. OK, that works for simple data models and building simple apps, but if you need to deviate it's problematic because, in some cases, .NET's affinity to auto-magic stuff means that there aren''t a lot of deep and insightful examples on the details.
>>
>>Case in point: LINQ to SQL and LINQ to Entity. You have a complex class model with all sorts of inheritance and List (of T) collection classes. And, as usally is the case especially with serialized data, you have heavy denormalization in your CLR class definitions. LINQ to SQL is somewhat forgiving but still a b*tch to work with in this scenario; LINQ to Entity is very unforgiving. ORM in it's infancy.
>>
>>I had this situation and I tried hard to be a good doobie and play with the latest entity model stuff with WCF. The best I could achieve after great gnashing of teeth was a throughput in the operation contracts (REST, POX) of about 100 rows per second. When I abandoned that architecture and moved to good 'ol SQLCommands and a judicious use of LINQ in my class constructors I attained about 250 rows per second. And that was BEFORE query optimization within SQL Server which is ongoing but I suspect I should be able to double the speed.
>
>Not exactly what you are speaking about but have you looked at (or tried) this approach:
>http://code.msdn.microsoft.com/LinqEntityDataReader
>
>Best,
>Viv