말씀하신대로 Lock Conflict... 에러는 두개 이상의 클라이언트에서 하나의 레코드를
수정하려고 할 때 발생합니다.

뉴스그룹을 뒤져보니, 님께서 생각하신 대로 뒤에 들어온 한쪽이 기다리도록 하는 방법에
대한 요청이 많던데... 답변은 인터베이스 설계상의 철학이므로 발생하는 에러메시지는
그대로 인정하고 잘 처리하는 것이 좋겠다는 내용이 압도적이더군요.

인터베이스는 락킹 디비가 아니라 버저닝 디비라고 하는군요.
MS SQL서버의 경우 동시 write 요청에 대해 먼저 들어온 쪽에서 무조건 락을 걸게 된다고 하는데,
인터베이스에서는 버저닝을 하므로(각각의 클라이언트는 각각의 '뷰'를 가짐) commit 동작으로
실제로 write가 일어날 때가 아니면 데드락은 생기지 않는다고 합니다.

만약 그리드를 사용해서 레코드를 수정하는 중에 그런 문제가 자주 발생한다면, 그리드에서
레코드를 에디트하려고 할 때 새로운 폼을 띄워서 입력하도록 하여 그리드에서 직접 에디트를
못하도록 막는 방법도 있겠구요.

다른 트릭으로는 try~except문으로 해당 익셉션을 받은 후 약간의 인터벌을 주면서 몇번까지
재시도해보는 것도 좋을 것 같습니다.
3회 정도 실패한 후에는 "다른 사용자가 같은 행을 수정중이므로 수정할 수 없습니다."
정도의 메시지를 출력하는 것도 좋겠네요.

그럼...


하기현 님이 쓰신 글 :
: Interbase6을 사용하며, 델파이6으로 컴파일했습니다.
:
: IB전용 콤포넌트들을 사용하였습니다.
: IBtransaction의 환경도 네가지 모두 적용해 봤지만
: 그래도 Read Committed를 사용하니 가장 안정적이더군요.
:
: A라는 테이블이 있는데, 두군데의 클라이언트에서
: 동시에 같은 레코드의 값을 수정하면,
: 'Lock Conflict on no wait transaction deadlock'
: 이란 메시지가 뜹니다.
:
: 제가 생각할때는 한쪽의 데이터가 수정할때까지 기다렸다가
: 다른 한쪽이 치고 들어가서 작업을 해줬으면 하는데...
:
: 제생각대로 안되나봅니다.
:
: 이것을 해결할 방법이 없습니까?
: