>In the case of large tables, one in FoxPro (600K recs) and the other in SQL, and you need to join them in your separate ADO.NET connections wouldn't you pretty much have to pull all the data over from both before you have them in object lists and can use LINQ?

Think about how you would do this with FoxPro code... same issue there, right?

You can always pre-filter the data to hopefully pull only the data that is relevant or as close as relevant before you start joining the data. Alternately it might be more efficient to just use a more procedural approach where you pull your primary data first, then pull the related data when needed using lazy loading. That's something you'd do in VFP most likely as well.

Cross DB queries are always pretty ugly...

+++ Rick ---


>>>To complicate matters: What if I need to join an EF entity (table) to a FoxPro table using the VFP Oledb driver? (This question is similar to my other question on cascading FoxPro queries, but a little different.)
>>
>>Same here - you can't do that with EF, but you sure can with ADO.NET and two separate connections pulling data from each source. As Paul pointed out you can pull the data into plain object lists and then use LINQ to merge the data as needed.
>>
>>This is really no different then what you would do if you didn't have an ORM for your data access :-)
>>
>>+++ Rick ---
>
>Thanks, Rick.
>
>In the case of large tables, one in FoxPro (600K recs) and the other in SQL, and you need to join them in your separate ADO.NET connections wouldn't you pretty much have to pull all the data over from both before you have them in object lists and can use LINQ?
>
>And taking this one step further to our real scenario this is all in WCF on one server serving many, many clients. Wouldn't this business of pulling in each table for a join blow out the server and kill performance completely?