views:

119

answers:

1

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
accountcode     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

+1  A: 

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.

David B
Sh*t. Sorry - we copied a simplified version of the query. I've edited the query so it is the full version. Apologies!!!
6footunder
Excellent! That was it thanks DB, only accountcode was a primary key! So i guess Linq could manage the join but not distinguish between the objects when the select was triggered? Cheers!
6footunder
Good to hear. One way to shoot the instance hydrator is to capture the query (sql profiler) and examine the results manually. If the database results don't match the instances returned, bingo - it has to be the instance hydrator.
David B