>Thanks, Paul. That's a good idea for the cascading selects.
>
>Not that it's your problem to solve, but one of our FoxPro databases is provided by a vendor and we won't be able to add sprocs to it and that is where most of our queries probably need to be.
>
>I looked at our tables and they are all 1252.

The database that contains the stored procs doesn't necessarily have to only use tables that are part of the same database. I'd think you'd be able to use/select from other tables as long as the pathing is correct.

I haven't had any problems with performance with VFP EF beyond the codepage issue. I'd expect the main overhead (besides the query itself) is mapping the results back into objects.

Having said that, I'm using the SqlQuery<T> and passing in raw SQL for almost all of my queries - that way I can be sure the queries would normally be optimized by VFP by making sure my WHERE clause matches the available index, ex.

string field1 = "ABC";
string field2 = "123;
var address = Context.Database.SqlQuery<Address>("SELECT a.* FROM Address a WHERE a.Field1 + a.Field2 = ? + ?", field1, field2).ToList();