We have the following query to give us a left outer join:
(from t0 in context.accounts
join t1 in context.addresses
on new { New_AccountCode = t0.new_accountcode, New_SourceSystem = t0.new_sourcesystem, New_Mailing = t0.new_MailingAddressString }
equals new { New_AccountCode = t1.new_AccountCode, New_SourceSystem = t1.new_SourceSystem, New_Mailing = t1.new_MailingAddressString } into t1_join
from t1 in t1_join.DefaultIfEmpty()
where
t0.statecode != 1 &&
t0.statuscode != 2 &&
t1.new_AccountCode == null &&
t1.new_SourceSystem == null &&
t1.new_MailingAddressString == null
select t0)
.OrderBy(o => o.new_accountcode)
.ThenBy(o2=>o2.new_sourcesystem)
.Skip(recordsProcessed)
.Take(recordBatchSize).ToList();
The issue is that if the left table (accounts) contains multiple rows with the same accountcode value, the result set contains the first row duplicated - so the second row with it's unique combination of accountcode, sourcesystem and mailingaddressstring is "overwritten".
Given:
accounts
accountcod开发者_如何学Pythone sourcesystem mailingaddressstring
10025 ss1 12345
10025 ss2 67891
addresses
accountcode sourcesystem mailingaddressstring
10025 ss1 12345
10025 ss2 67891
we get:
accountcode sourcesystem mailingaddressstring
10025 ss1 12345
10025 ss1 12345
Are we doing something wrong with the select statement?
Thanks
Ah, well that's rather much better. The left join looks just peachy to me... but all does not sit well with me.
- Are any (or all) of these columns the primary key?
- What is the lifecycle of the datacontext? Has it been used to query before? Has it been used to save records before?
Suppose I have an Order record with an OrderId set as primary key in the dbml (but not in the database, allowing duplicate records to be created). If I were to query for Orders, and OrderID = 5 is in there twice... when the datacontext sees the first instance with OrderID, it starts tracking it. When it sees the second instance, instead of hydrating the row, it returns the instance it already returned with ID=5.
If my query result is an anonymous type, I wouldn't see this behavior, as the anonymous type has no primary key in the dbml and is not tracked by the datacontext.
精彩评论