질문과 대답

연결 문자열이 올바르고 SQL Server 인스턴스가 실행 중인지 확인하세요. LINQ to SQL을 사용하려면 명명된 파이프 프로토콜도 사용하도록 설정해야 합니다. 자세한 내용은 연습으로 학습을 참조하세요.

SubmitChanges를 호출하여 결과를 데이터베이스에 저장해야 합니다.

일반적으로 연결은 쿼리 결과를 사용할 때까지 유지됩니다. 모든 결과를 처리하는 데 시간이 많이 걸릴 것으로 예상되고 결과를 캐시해도 상관 없다면 쿼리에 ToList ¦ Àû ëÇÏ Ê Ã À. 각 개체를 한 번만 처리하는 일반적인 시나리오에서는 DataReader 및 LINQ to SQL 모두에서 스트리밍 모델을 사용하는 것이 더 효과적입니다.

세부적인 연결 사용은 다음에 따라 달라집니다.

• 연결 개체를 사용하여 DataContext를 만든 경우의 연결 상태

• 연결 문자열 설정(예: MARS(Multiple Active Result Sets) 사용). 자세한 내용은 MARS(여러 활성 결과 집합)를 참조하세요.

LINQ to SQL에는 설정 기반의 업데이트 명령이 없지만 다음 기술 중 하나를 사용하여 쿼리 없이 업데이트할 수 있습니다.

• ExecuteCommand를 사용하여 SQL 코드를 보냅니다.

• 개체의 새 인스턴스를 만든 후 업데이트에 영향을 주는 현재 값(필드)을 모두 초기화합니다. 그런 다음 DataContext를 사용하여 개체를 Attach에 연결하고 변경할 필드를 수정합니다.

LINQ to SQL에는 생성된 SQL 코드를 검사할 수 있는 도구가 여러 가지 있습니다. 그 중에서도 Log가 가장 중요합니다. 자세한 내용은 디버깅 지원을 참조하세요.

LINQ to SQL에서는 다음과 같은 두 가지 방법으로 데이터베이스에서 생성된 값을 저장 프로시저를 통해 반환합니다.

• 출력 결과에 이름을 지정하는 방법

• 출력 매개 변수를 명시적으로 지정하는 방법

다음은 잘못된 출력의 예제입니다. LINQ to SQL은 결과를 매핑할 수 없기 때문에 항상 0을 반환합니다.

create procedure proc2

as

begin

select max(i) from t where name like 'hello'

end

다음은 출력 매개 변수를 사용하여 얻은 올바른 출력의 예제입니다.

create procedure proc2

@result int OUTPUT

as

select @result = MAX(i) from t where name like 'hello'

go

다음은 출력 결과에 이름을 지정하여 얻은 올바른 출력의 예제입니다.

create procedure proc2

as

begin

select nax(i) AS MaxResult from t where name like 'hello'

end

자세한 내용은 저장 프로시저를 사용하여 작업 사용자 지정을 참조하세요.

LINQ to SQL의 코드 생성은 DataContractSerializer serialization을 지원합니다. XmlSerializer 또는 BinaryFormatter는 지원하지 않습니다. 자세한 내용은 Serialization을 참조하세요.

Object Relational Designer의 컨텍스트 네임스페이스 및 엔터티 네임스페이스 속성을 각 DBML 파일에 대한 고유 값으로 설정합니다. 이렇게 하면 이름/네임스페이스 충돌이 해결됩니다.

LINQ to SQL은 ID(자동 증분)와 rowguidcol(데이터베이스에서 생성된 GUID) 및 타임스탬프 열에 대해서만 이와 같이 기본값을 적용합니다. 그 외의 경우에는 IsDbGenerated=true 및 AutoSync=Always/OnInsert/OnUpdate와 같이 속성을 직접 설정해야 합니다.

예. 다음 예제에서처럼 첫 번째 로드 옵션을 덮어쓰지 않습니다.

Dim dlo As New DataLoadOptions()
dlo.LoadWith(Of Order)(Function(o As Order) o.Customer)
dlo.LoadWith(Of Order)(Function(o As Order) o.OrderDetails)

DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Order>(o => o.Customer);
dlo.LoadWith<Order>(o => o.OrderDetails);

LINQ to SQL 런타임은 SQL Server Compact 3.5를 지원하지만 Object Relational Designer는 지원하지 않습니다. 이 경우에는 고유 엔터티 클래스를 만들어 적절한 특성을 추가해야 합니다.

관계를 만드는 것만으로는 부족합니다. 판별자 열, 기본 클래스 판별자 값 및 파생 클래스 판별자 값 등의 정보를 제공해야 합니다.

아니요, 사용할 수 있는 공용 공급자 모델은 없습니다. 현재 LINQ to SQL은 SQL Server 및 SQL Server Compact 3.5만 지원합니다.

사용자 입력을 연결하여 만든 기존 SQL 쿼리의 경우에는 SQL 삽입 공격이 상당히 큰 위협 요소였습니다. LINQ to SQL에서는 쿼리에 SqlParameter를 사용하여 이러한 삽입 공격을 방지합니다. 즉, 사용자 입력은 매개 변수 값으로 변환됩니다. 이 방법을 사용하면 사용자 입력을 통해 악의적인 명령이 사용되는 문제를 방지할 수 있습니다.

이와 같은 고급 시나리오에서는 다음과 같은 단계를 수행하세요.

1. .dbml 파일에서 IsReadOnly 플래그를 True로 변경하여 속성을 수정합니다.

2. 부분 클래스를 추가합니다. 읽기 전용 멤버에 대해 매개 변수가 있는 생성자를 만듭니다.

3. 기본 UpdateCheck 값(Never)을 검토하여 애플리케이션에 사용할 수 있는 올바른 값인지 확인합니다.

   주의

   Visual Studio에서 Object Relational Designer를 사용하는 경우 변경 내용을 덮어쓸 수 있습니다.

예, System.Data.Linq.dll 어셈블리도 AllowPartiallyTrustedCallersAttribute 특성이 표시된 .NET Framework 어셈블리 중 하나입니다. .NET Framework에서 이 특성이 표시되지 않은 어셈블리는 완전히 신뢰할 수 있는 코드에서만 사용할 수 있습니다.

일반적으로 LINQ to SQL에서는 ‘신뢰’가 보통으로 설정된 웹 애플리케이션에서 LINQ to SQL 어셈블리에 액세스할 수 있도록 설정하여 부분적으로 신뢰할 수 있는 호출자의 어셈블리 사용을 허용합니다.

데이터베이스에 뷰를 만들어 엔터티를 해당 뷰에 매핑할 수 있습니다. LINQ to SQL에서는 테이블과 마찬가지로 뷰에 대해서도 동일한 SQL을 생성합니다.

DataContext의 인스턴스는 다시 사용하지 마세요. 각 DataContext는 하나의 특정 편집/쿼리 세션에 대한 상태(ID 캐시 포함)를 유지합니다. 데이터베이스의 현재 상태를 기반으로 새 인스턴스를 사용하려면 새 DataContext를 사용하세요.

기본 ADO.NET 연결 풀링은 사용할 수 있습니다. 자세한 내용은 SQL Server 연결 풀링(ADO.NET)을 참조하세요.

이 동작은 의도된 것입니다. LINQ to SQL은 첫 번째 인스턴스와 동일한 인스턴스/값을 계속해서 반환합니다. 데이터를 업데이트할 경우에는 낙관적 동시성을 사용합니다. 이 경우 현재 데이터베이스 상태를 원래 데이터와 비교하여 데이터가 변경되지 않았는지 확인합니다. 데이터가 변경된 경우 충돌이 발생하고 애플리케이션에서는 이 문제를 해결해야 합니다. 애플리케이션에서는 한 가지 옵션으로 원래 상태를 현재 데이터베이스 상태로 다시 설정한 후 업데이트를 다시 시도합니다. 자세한 내용은 방법: 변경 충돌 관리를 참조하세요.

ObjectTrackingEnabled를 false로 설정하여 캐싱 및 변경 추적을 해제할 수도 있습니다. 이렇게 하면 쿼리할 때마다 최신 값을 검색할 수 있습니다.

읽기 전용 모드에서는 컨텍스트에서 변경 내용을 추적하지 않습니다.

참고 항목

• 참조
• 문제 해결
• LINQ to SQL의 보안