Thanks
Ray Akkanson

Is this valid???
ObjectQuery c2a = db.ADMINISTRATION;
IQueryable AGREEMENT_IDS =
from com2a in c2a
where com2a.DESC.Contains(keyword)
from com2b in com2a.PACK
from com2c in com2b.AGREEMENT_PACK
join com2d in db.AGREEMENT on com2c.AGREEMENT equals com2d <————- valid??
select com2d.AGREEMENT_ID;

thank you for an effort you’ve put into this post.
I have read all and it refreshed waht already know.
Refreshing is good because it lets you remember the "thing" for longer.

Your effort is appreciated

Regards
Mariusz

i try select cluase clause in LINQ query but in L2S/L2EF not supported!! and also i don’t want create DTO object(My DB has more than 200 table)
what’s your opinion?

I am trying to write a "testable code" as part of my learning process. Would look forward if you could write a post on writing testable code using C#.
Thanks

Simply adding DefaultIfEmpty() to the inner join syntax does the trick, although you spent so much time deprecating it in the original article.

Response: My goal is to get LINQ users to think in terms of object graphs rather than relational sets. It’s a critical difference which many miss because LINQ looks so much like SQL. But if your goal is to throw the results into a visual control designed for a relational set, then there’s nothing particularly wrong with it.

I find it quite reasonable to want a result set that looks like

select t1.ContactName, t2.Freight from Customers t1
left join Orders t2 on t1.CustomerID = t2.CustomerID

Response: I don’t think so, but then again, my goal is not to "immediately chuck the result set into a DataGridView." Yours might be, which is fine, but that just means your needs are different than mine. As for how to meet your needs, read on…

In the self referencing Table Employees the field ReportsTo is nullable and actually contains nulls.
It is unusual for a foreign key to be nullable between 2 SEPARATE tables.
Try left joining Customers and Orders.
Although CustomerID in Orders is nullable, there are no Orders without a CustomerID.

Response: Not in the data delivered with Northwind, no, but it’s certainly possible.

If Orders is the left table, an inner join and an outer join produce the same result anyway, and yield only those customers who have placed orders.
If Customer is the left table, the fields of Customer.Order are inaccesible.

Response: That is wrong, on several counts. First, the property is Orders, not Order. It’s 1..*, not 1..1. Second, you certainly can use the properties of Orders in a query. The following query works fine, for example:
var q = from c in context.Customers
from o in c.Orders
select new
{
Name = c.ContactName,
Freight = o.Freight
};

It requires a nested foreach to convert the result set to a List.

Response:No. What I think you’re trying to say is "I don’t know how to convert the result to a "flattened, SQL-like" tabular result set instead of an "object-like," hierarchical tree of customers and orders without a nested foreach (or a join). But it’s quite possible. I’ve already shown the "inner join" version above. Here’s the "left join" version:
var q = from c in context.Customers
from o in c.Orders.DefaultIfEmpty()
select new
{
Name = c.ContactName,
Freight = o.Freight
};

I wouldn’t describe this as an improvement over ‘join’ where I can immediately chuck the result set into a DataGridView.

Response:See the query above. This isn’t how I’d do it, because most use cases of such tabular result forms tend to want to group them back into hierarchies anyway (think of every reporting tool ever created). But it’s certainly possible. And again, the join is just noise. The association properties make it redundant and messy.

Maybe you have an elegant solution to left joining Customers with Orders, i.e showing ALL Customers with or without Order details ?

I think a lot of people have missed the significance of:

from s in context.Employees
from e in s.Employees

as a way of doing joins. Once you understand what you’re looking at, it’s obvious and makes perfect sense. It might make sense to highlight this in a future post. And again, thanks for the SO help.