FileMaker에서 어려움 No.1

그렇다면 아마도 손상 레코드입니다.
id 등으로 검색하면 찾을 수는 있지만 데이터가 보이지 않습니다. .
이른바 「새하얀 레코드」가 되어 버리는 현상입니다.
이런 느낌.

미입력이 아니라 데이터가 보이지 않게 되어 버리는 상태입니다.

파손 이유를 모른다

그런데, 데이터가 보이지 않는 것은 물론 곤란합니다만,
가장 곤란한 것은, 「파손 이유를 모른다」라고 하는 것입니다.

무언가의 스크립트로 부서지고 있습니까?
혹시 작업의 방법이 나빠 (작업 도중에 LAN을 끌어당기는 건가) 부서져 버리는 것인가··

얼마나 자주 일어나는지

PTNA에서는 많은 때에 10일에 7건 정도의 페이스로 망가져 갑니다.
※ 물론 데이터는 즉시 복구할 수 있도록 하고 있습니다만.

그 때문에, 담당자는 매일 새롭게 파손된 레코드가 없는지, 체크를 하고 있다고 하는 것이었습니다.

파손 기록을 방지하기 위한 길

그렇다고 해서, 9월에 조사를 했으므로 그 방법을 정리합니다.

깨진 타이밍을 조사한다←이마코코

깨진 직전의 작업을 담당자에게 확인하여 근본 원인을 파악한다

해결

깨진 타이밍 조사

오이타 앞 두는 것이 길어졌습니다만, 여기부터가 본제입니다.

손상된 레코드를 찾는 방법

onRecordBroken

언제 망가졌는지 알고 싶기 때문에 onRecordBroken이라는 트리거가 있으면 최적이었지만 구현되지 않은 것 같습니다.

손상된 레코드만 검색

그렇다면 손상된 레코드 만 검색하는 방법을 조사했습니다. 1
이것은 알고 보면 간단하고,

수정 시간이 비어있는 레코드

이었다.

도유?

레코드 손상이 자주 발생하는 파일의 경우,

수정 시각을 필드에 들기

FileMaker의 "수정 정보 : 시간"을 보관 유지하도록 정의

하고 있습니다.


즉, 뭔가 수정하면 FileMaker가 마음대로 수정 시간을 넣어주는 설정으로하고 있습니다.

그리고 이 "수정 정보"는 레코드가 손상될 때, 공백이 들어 버리는 것 같습니다. 2
그러면 수정 날짜 및 시간 필드가 빈 레코드를 검색하여 손상된 레코드 수를 확인할 수 있습니다!



파손 레코드수를 체크할 수 있으면, 정기적으로 체크해 레코드수가 늘어난 기간에 망가진 것을 알기 때문에, 그 기간에 행해진 오퍼레이션으로부터 근본 원인을 찾을 수 있을 것이라는 혼담입니다. ↩

그 외의 필드는, 보이지 않고 취득도 할 수 없지만, 데이터는 들어 있는 것 같고, 검색에는 사용할 수 있다고 하는 수수께끼의 사양입니다. ↩