동일한 데이터베이스가 여러 서버의 복제 복사본으로 상주하는 경우가 있습니다. 문제는 서버가 모두 기본 날짜 형식이 같지 않다는 것입니다.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 비교는 날짜 형식의 차이를 조정할 수없는 것 같습니다. 어떤 아이디어 나 제안.
코드를 위의 스 니펫에 올바르게 복사 했습니까? 대괄호는 필드 이름의 둘레에 있어야하지만 스 니펫에서는 전체 표현식을 반올림합니다. 전체 텍스트 인덱스를 검색하는 서버와 동일한 서버에 DateTime 개체를 만드는 경우 둘 다 동일한 형식을 유지해야합니다. –
전체 텍스트 검색 오류가 발생하면 항상 동일한 검색을 수동으로 실행하고 실제로 해당 서버에서 작동하는 형식이 있는지 확인하십시오. 필자는 과거에 필드의 데이터 유형이 다를 수 있다는 제안을 좋아합니다. 해당 필드에 문자열이있는 오래된 문서가있는 경우 현재 다른 데이터 유형이있을 수도 있습니다. 이 경우 오류가있는 문서를 수정해야합니다. 필드가 문자열인지 날짜인지 여부는 우연히 결정됩니다. –