2009-06-16 4 views
12

다음 LINQ to 엔티티 쿼리의 결과에 텔 레릭 RadGrid 및 일반 바닐라 ASP.NET GridView를 바인딩하는 데 문제가 있습니다. 두 경우 모두 그리드에 정확한 행 수가 포함되지만 첫 번째 행의 데이터 만 다른 모든 행에 복제됩니다. 이 코드의 반환 값을 격자의 DataSource 속성에 직접 지정합니다.엔티티에 LINQ를 사용하여 데이터 바인딩시 중복 행

public IEnumerable<DirectoryPersonEntry> FindPersons(string searchTerm) 
{ 
    DirectoryEntities dents = new DirectoryEntities(); 
    return from dp in dents.DirectoryPersonEntrySet 
      where dp.LastName.StartsWith(searchTerm) || dp.Extension.StartsWith(searchTerm) 
      orderby dp.LastName, dp.Extension 
      select dp; 
} 

ADDED :

DataTable ret = new DataTable(); 
    using (SqlConnection sqn = new SqlConnection(ConfigurationManager.ConnectionStrings["WaveAdo"].ConnectionString)) 
    { 
     SqlDataAdapter adap = new SqlDataAdapter("select * from DirectoryPersonList where LastName like '" + searchTerm + "%' order by LastName ", sqn); 
     sqn.Open(); 
     adap.Fill(ret); 
    } 
    return ret; 

: LINQ하여 SQL Server에 전송

  1. 쿼리 작동이 작동 대체 일반 ADO.NET 코드입니다.
  2. 결과를 반환하기 전에 LINQ 쿼리 결과를 반복하면 동일한 중복이 발생합니다.
  3. 바인딩하기 전에 호출 메서드에서 LINQ 결과를 반복하면 동일한 중복이 발생합니다.

UPDATE : 마크 아래 자갈, 나는 EF 디자이너가 내 엔티티 클래스에 대한 엔티티 키에 아주 무식한 추측을 만들었다 발견에서 매우 논리적이고 피팅의 조언을 바탕으로, 첫 번째 필드 부서 목록에는 다른 모든 레코드에서 공유되는 약 7 개의 항목 만 있습니다.

이것은 실제로 중복의 원인입니다. 엔터티 키를 변경하거나 제거 할 수만 있다면 Etch-a-Sketch의 모든 비즈니스 로직을 갖춘이 EF 디자이너는 키를 선택하기가 힘들어 반복적으로 최선을 다하고 키를 변경하기 위해 외부에 잠근 채로 나를 비웃을 수 있습니다.

+0

테이블에 중복 된 항목이 없는지 확인하십시오. 쿼리가 정확합니다. –

+0

@Alexander, 예, 확신합니다. 동일한 뷰에 대한 일반 DataTable 쿼리는 그리드가 올바르게 바인딩되도록합니다. – ProfK

+0

코드를 더 자세히 보여주십시오. 둘 다 작동하고 문제. –

답변

30

borked 기본 키가있는 것처럼 보입니다. LINQ-to-SQL 및 EF의 "ID 관리"측면은 동일한 개체 유형에 대해 동일한 기본 키 값을 볼 때마다 동일한 인스턴스를 되돌려 주어야한다는 것을 의미합니다. 데이터 주어진 예를 들어

: LINQ에서 개체를 반복 때 id을 생각하면 그런

id  | name  | ... 
-------+------------+------ 
1  | Fred  | ... 
2  | Barney  | ... 
1  | Wilma  | ... 
1  | Betty  | ... 

기본 키, 그것은 "당신에게"프레드 "를 제공하기 위해을 강제로 바니 ","프레드 ","프레드 ". 본질적으로 id 1을 다시 보았을 때 다른 열을 보지도 않습니다 - 단순히 ID 캐시에서 id 1로 인스턴스를 가져오고 이전에 준 것과 동일한 Fred 인스턴스를 제공합니다. 이 아닌 경우 id이 기본 키이므로 각 행을 별도의 개체로 취급합니다. 따라서 필드 중 하나에서 다른 레코드와 동일한 값을 가지면 (정확히는 비정상적 일 수 있습니다).

기본 키 (DBML/EDM 모델)로 표시된 모든 필드가 실제로 행마다 고유한지 확인하는 것이 좋습니다.위의 경우 id 열은 고유 식별자를 명확하게 나타내지 않으므로 기본 키로 적합하지 않습니다. LINQ-to-SQL/EF 디자이너에서 해당 표시를 해제하십시오.


업데이트 : 특히, 디자이너의 다양한 속성에 대한 "엔티티 키"속성을보고 - 당신이 뷰를 쿼리하는 경우 특히. 적합한 열 (즉, 행을 고유하게 만드는 열)에 대해서만 "엔터티 키"가 true로 설정되어 있는지 확인하십시오. 잘못 설정된 경우 false로 설정하십시오. 노란색 키 아이콘으로도 볼 수 있습니다. 이는 레코드의 고유 한 식별자 인 경우에만 나타납니다.

+3

+1 borked 사용. 또한 좋은 대답. –

+0

@Marc, 좋은 물건, 당신은 가장 정확하게 문제를 확인했습니다. 그러나 문제 열에서 엔티티 키 플래그를 제거하는 것이 좋지만이 작업을 수행 할 수는 없습니다. – ProfK

+0

엔터티 집합에 대한 엔터티 키는 변경할 수 있지만 테이블에는 변경할 수 없으므로 매핑이 'borked'가됩니다. – ProfK

1

괄호 안에 링크 쿼리를 래핑하고 .Distinct() 확장명을 사용하면?

public IEnumerable<DirectoryPersonEntry> FindPersons(string searchTerm) 
{ 
    DirectoryEntities dents = new DirectoryEntities(); 
    return (from dp in dents.DirectoryPersonEntrySet 
      where dp.LastName.StartsWith(searchTerm) || dp.Extension.StartsWith(searchTerm) 
      orderby dp.LastName, dp.Extension 
      select dp).Distinct(); 
} 
+0

이렇게하면 유사한 중복으로 더 이상한 결과를 얻을 수 있지만 동일한 기준에 맞는 다른 항목을 얻을 수 있습니다. 차이점을 블로그로 올립니다. – ProfK

0

작업 쿼리와 깨진 쿼리의 차이점 중 하나는 orderby 절입니다. 엔티티에 대한 Linq의 orderby 구현에서 documented bug을 찾았습니다 ... 다른 것이있을 수 있습니다.

깨진 쿼리에서 orderby를 제거하고 여전히 중복이 있는지 확인하십시오.

또 다른 차이점은 where 절의 OR입니다. [dp.LastName.StartsWith (searchTerm)]의 첫 번째 부분 만 사용하여 중복 된 부분이 있는지 확인하십시오.

0

동일한 문제에 직면하고 해결 방법으로 해결했습니다. 다른 사람들이 이곳에 오는 데 도움이 될 수 있으므로 여기에 게시하고 있습니다. 대신 선택 DP의

는 중복을 반환하지 않습니다

select new <ObjectName> 
{ 
a = v.a 
b = v.b 
}. 

이를 사용합니다.

관련 문제