2014-07-19 3 views
0

동일한 데이터베이스가 여러 서버의 복제 복사본으로 상주하는 경우가 있습니다. 문제는 서버가 모두 기본 날짜 형식이 같지 않다는 것입니다.FTIndex 검색에서 날짜 비교 오류가 발생했습니다.

따라서 서버 A의 날짜 형식은 mm-dd-yyyy이고 서버 B는 yyyy-mm-dd입니다.

따라서 서버 A에서 실행되는 프로세스는 CompletedDate라는 필드를 설정하고 06-25-2014의 날짜를 저장합니다. 이 문서는 사용자 프로세스의 일부는이 코드를 사용하여 FUL 텍스트 인덱스에서 검색입니다

서버 B로 복제 :

var dt:NotesDateTime = session.createDateTime("Today"); 
dt.adjustDay(-30)); 
var dString:String = dt.getDateOnly(); 
var qString = "([WFSCompletedDate > " + dString + "])"; 
var dc:NotesDocumentCollection = appDB.FTSearch(qString); 

는 클라이언트 액세스 서버 A의 DB dString에 대한 값의 경우 오늘 날짜 - 30 일 = 06-19-2014이며 검색에 성공했습니다. 서버 B에서 액세스하는 경우 dString은 2014-06-19이며 FTSearch는 오류를 일으키지 않는 것뿐만 아니라 HTTP JVM : com.ibm.xsp.exception.EvaluationExceptionEx : FTIndex가 실행될 때 JavaScript 액션 표현식을 실행하는 동안 오류가 발생합니다. 2014-06-19를 2014 년 7 월 19 일까지의 문서 날짜로 평가하려고 시도합니다.

모든 복제본 서버가 동일한 기본 날짜 형식을 적용 할 수있는 위치에 있지 않으며 어떤 서버에서나 만들 수있는 데이터베이스의 문서에 날짜가 혼합되어있을 수 있습니다. 정상 날짜 형식화는 이러한 차이점을 처리하는 것으로 보이지만 FTIndex 비교는 날짜 형식의 차이를 조정할 수없는 것 같습니다. 어떤 아이디어 나 제안.

+0

코드를 위의 스 니펫에 올바르게 복사 했습니까? 대괄호는 필드 이름의 둘레에 있어야하지만 스 니펫에서는 전체 표현식을 반올림합니다. 전체 텍스트 인덱스를 검색하는 서버와 동일한 서버에 DateTime 개체를 만드는 경우 둘 다 동일한 형식을 유지해야합니다. –

+0

전체 텍스트 검색 오류가 발생하면 항상 동일한 검색을 수동으로 실행하고 실제로 해당 서버에서 작동하는 형식이 있는지 확인하십시오. 필자는 과거에 필드의 데이터 유형이 다를 수 있다는 제안을 좋아합니다. 해당 필드에 문자열이있는 오래된 문서가있는 경우 현재 다른 데이터 유형이있을 수도 있습니다. 이 경우 오류가있는 문서를 수정해야합니다. 필드가 문자열인지 날짜인지 여부는 우연히 결정됩니다. –

답변

0

Notes 클라이언트에서 검색하여 확인하는 것이 좋습니다. 검색 창을 사용하면 전체 텍스트 색인이 예상하는 데이터 유형을 확인하고 구문 문제를 식별 할 수 있습니다. 필자는 검색 문자열을 인쇄 한 다음 Notes 클라이언트에서이를 사용하여 실수를하지 않은 것을 다시 확인하는 경향이 있습니다.

+0

낯선 사람과 낯선 사람이 생겼습니다. 원래 검색 창을 사용하여 제안한대로 쿼리를 만들었으므로 다시 돌아 왔습니다. 서버 A의 DB에서 [WFSCompletedDate]> 2014 년 6 월 21 일 입력하고 예상했던 결과를 얻었습니다. 즉, 한 번 성공했습니다. 서버 B의 DB (이는 새로운 복제본 임)에서 동일한 결과를 얻었으므로 조회수가 없습니다. 다른 날짜 형식을 시도했지만 차이는 없습니다. 나는 훌륭한 Domino Admin이 아니지만 서버에 영향을 줄 수있는 Notes.ini 설정이 있습니까?나는 완전히 손해를보고있다. –

+0

매우 이상합니다. 인덱스를 삭제하고 다시 만들려고 할 가치가 있습니다. UNK 테이블에 문제가있는 경우 블로그 게시물에서 다루었 듯이 쉽지 않습니다. –

+0

데이터베이스를 삭제하지 않고 새 복제본을 만들면 새 UNK 테이블이 만들어 집니까? 그 이유는 WFSCompletedDate 필드가 포함 된 각 문서에 특정 날짜를 할당 한 이후에 수행 한 작업이기 때문입니다. –

0

청구서 - 저장된 값의 날짜/시간 구성 요소에서 날짜 전용 문자열을 작성하여 dstring 값을 원하는 형식으로 강제 설정하려고 시도 했습니까? 내가 말하려는 것은 월, 일, 년을 꺼내서 그 부분들로부터 날짜를 만드는 것입니다.

+0

그 문제는 저장된 값 형식이 무엇인지 알지 못하며 각 서버마다 다를 수 있습니다.그러나이 경우 날짜 WFSCompletedDate는 예정된 LS 에이전트에서 설정되므로 dd-mm-yyyy 또는 알려진 형식으로 설정할 수 있다고 가정합니다. 그런 다음 dString을 동일한 순서로 빌드하는 것이 좋습니다. 이것은 약간의 고통이 될 것이지만 아마도 효과가있을 것입니다. 나는 그것을 시험해보고 무슨 일이 일어나는지보아야 할 것이다. 비교는 서로 다른 형식의 두 날짜를 비교할 수 있어야합니다. –

+0

John - SSJS의 날짜를 dd/mm/yyyy로 형식화했으며 서버 A (WFSCompletedDate 날짜가 설정되었고 기본 날짜가 dd/mm/yyyy 인 검색)에서 올바르게 작동합니다. 동일한 데이터를 정확하게 동일한 데이터를 실행하는 서버 B에서 기본 날짜 yyyy/mm/dd EvaluationException 오류와 함께 설정합니다. 그래서 비교기 ([WFSCompletedDate "+ dString +"]) 형식에 관계없이 충돌합니다. dString (mm/dd/yyyy, dd/mm/yyyy, yyyy.mm.dd)하지만 서버 A에서는 dString을 mm/dd/yyyy 또는 dd/mm/yyyy로 전달할 때 실제로 작동합니다. –

+0

은 s.getInternational()을 사용합니다. isDateDMY() 여기서 s는 NotesSession이고 isDateMDY() 및 isDateYMD() –

0

내가 아는 한 FT 검색 구문은 로케일에 독립적입니다. 필드에 날짜/시간 값이있는 한 항상 "월/일/년"형식을 허용합니다. 데이터 시간 값은 로케일과 관계없이 저장됩니다.

또한 [FIELDNAME > VALUE] 형식을 사용했음을 확인했습니다. 올바른 형식은 [FIELDNAME] > VALUE (here)

일 수밖에 없기 때문에 다른 서버에서 작동하는 것이 놀랍습니다. 문제는 코드에서 아마도 dString 일 것입니다. 다음과 같이 시도하십시오.

var dt:NotesDateTime = session.createDateTime("Today"); 
dt.adjustDay(-30); 
var jdt:java.util.Date=dt.toJavaDate(); 
var formatter=new java.text.SimpleDateFormat("MM/dd/yyyy"); 

var dString = formatter.format(jdt); 
var qString = "([WFSCompletedDate] > " + dString)"; 

var dc:NotesDocumentCollection = appDB.FTSearch(qString); 
+0

Serdar - 제안한 변경 사항을 적용했습니다. 문서를 생성 한 서버가 정상적으로 작동하지만 (여전히 있음) 여전히 EvaluationException이 발생합니다. 내 생각 엔 문제를 일으키는 두 서버 간에는 다른 다른 것이 있지만 무엇을 모를 것입니다. 파고 계속해서 내가 알아낼 수 있는지 알아봐. 나는 qString이 훨씬 더 복잡하기 때문에 date evaaluation과 확실히 관련이있다.하지만 날짜 비교를 제거하면 두 서버에서 동일하게 작동한다. –

+0

로그에 특별한 오류 메시지가 있습니까? –

+0

하나 더 문제가 있는지 확인하십시오. UNK 테이블 (각 복제본마다 다름)에 알려진 문제점이 있습니다. 필드가 이전에 텍스트 였고 나중에 날짜/시간으로 변환 된 경우 FTSearch 문제가 표시 될 수 있습니다. 이를 확인하려면 다른 날짜/시간 필드를 사용해보십시오. Paul Withers : http://www.intec.co.uk/full-text-search-musings/ –

관련 문제