편지 병합, 쿼리 문자열을 반환 잘못된 레코드

Question

나는 단어 자동화 \의 편지 병합에 관한 문제, 내가 선택하고 예상대로 "="연산자, 모든 작업을 사용하는 경우

워드 2007에서 명령 및 SQL 문장을 쿼리 문자열이있다.

doc.MailMerge.DataSource.QueryString = 
"SELECT * FROM \"TableName\" WHERE \"Id\" = 10"; 

내가 선택하고 "LIKE"연산자를 사용하는 경우, 그것은하지 않습니다

doc.MailMerge.DataSource.QueryString = 
"SELECT * FROM \"TableName\" WHERE \"EmailAddress\" LIKE '%com%'"; 

은 "LIKE"연산자를 이해하고 그냥 건너 뛸 수없는 말씀처럼 보인다. 테이블의 모든 레코드를 반환합니다.

querystring에서 "like"를 사용할 수있는 방법이 있습니까?

업데이트 : 실제로 MailMerge.Execute는 LIKE 문과 함께 올바르게 작동합니다. 문제는 조금 다릅니다. 시스템에 RecordCount (doc.MailMerge.DataSource.RecordCount)가 표시되고 잘못된 값을 반환합니다 (테이블의 모든 레코드 수를 반환합니다). LIKE 문이 QueryString에서 사용 중이면 Word에서 레코드 수를 확인할 수없는 것처럼 보입니다.

Answer 1

수행 할 수있는 작업은 데이터 소스에 따라 다릅니다.

인식되는 Word 문서 형식 (.doc, .rtf, .docx 등) 또는 Word가 텍스트 파일 변환기를 통해 열리는 경우 Word는 사용자가 필드를 정의 할 수 있도록하는 매우 간단한 내부 내부 언어를 사용합니다 당신은 단순한 WHERE 조건과 간단한 ORDER BY을 원한다. (즉, 정렬/필터 대화 상자에서 수행 할 수있는 작업). 당신은 얻지 못한다 "LIKE"

엑세스 나 엑셀과 같은 Jet 데이터 소스라면 SQL의 Jet Dialect와 Jet 와일드 카드 (?와 *) 또는 SQL 표준 와일드 카드 (_와 %) 소스와 연결 방법에 따라 다릅니다. 일반적으로 LIKE을 가져와 _ 및 %를 사용할 수 있어야하지만 DDE를 통해 연결된 일부 데이터베이스에는 사용할 수 없어야합니다.

SQL Server, Oracle 등과 같은 다른 모든 경우에는 이론상 해당 서버에 적합한 SQL 언어를 얻습니다. 그러나 Word에서 OLE DB 쿼리 (Office 데이터 원본 개체, ODSO)를 처리하기 위해 사용하는 코드 비트는 쿼리 문자열을 보내기 전에 혼란에 빠질 수 있습니다. 댓글에서 통합

일부 노트 :

(가) "포함"

는 SQL의 LIKE 절에 말씀의 정렬/필터 대화 상자 결과에 옵션을 제공합니다. SQL Server의 경우 SQL 절은 다음과 같습니다.

"LIKE N'%com%'" 

("N"에주의하십시오).

기본 OLE DB 연결과 이전 SQLOLEDB.1 공급자를 사용하면 간단한 예제가 올바르게 필터링됩니다 (Word 2010 + SQL Server 2008 R2, 기본 OLE DB 연결 및 이전 SQLOLEDB.1 공급자). ODBC를 통해 연결하고 열이 유니 코드 인 경우 문제가 발생합니다 열 (NVARCHAR 등)하지만 유니 코드 열의 데이터가 표시되지 않습니다. 열 형식이 메모와 같은 긴 형식이고 %가 128 자 또는 일부 일치해야하는 경우 문제가 발생할 수 있습니다. 이 경우 SQL Server에 대한 규칙이 무엇인지 기억하십시오.

SQL Server 프로파일 러는 예기치 않은 쿼리 결과를 조사하기위한 유용한 서버 측 도구가 될 수 있습니다.이 경우 OP는 쿼리가 예상대로 실행 중이지만 RecordCount (doc.MailMerge.DataSource.RecordCount)은 검색된 레코드 수가 아닌 테이블의 모든 레코드 수를 반환한다는 것을 발견했습니다.

Recordcount이 올바른 값을 반환하는지 여부는 OLE DB 공급자 및/또는 해당 설정에 따라 다릅니다. 이러한 이유로 카운트에 의존하기보다는 "마지막 레코드"를 테스트하기 위해 노력하는 VBA 샘플 코드를 볼 수 있습니다.

개인적으로 필자는 별도로 쿼리를 실행하여 카운트 (*)를 얻는 것을 고려할 것이지만 물론 검색을 수행 할 때 실제 레코드 수가 변경 될 가능성이 있습니다. (FWIW 나는이 시나리오에서 도움이되는 SQL 트랜잭션을 사용할 수있을 지 의심 스럽지만 시도해 볼만한 가치가있을 수 있습니다.)