박지훈.임프님의 답변에 진심으로 감사드립니다..그런데..
어떤 예외처리를 날려야 하죠?


  if Dm1.IBTransaction2.InTransaction then
  begin
  try
  ExecSql;
  Dm1.IBTransaction2.Commit;
  except
  Dm1.IBTransaction2.Rollback;
  Application.MessageBox('저장에 실패하였습니다.','저장실패', MB_OK);
  end; //Try
  end; //if

이렇게 했는데도 예외 처리가 안되는것은 무엇때문일까요?
예외처리하는 예제를 한번 알려주시면 안되나요?
   

박지훈.임프 님이 쓰신 글 :
: 말씀하신대로 Lock Conflict... 에러는 두개 이상의 클라이언트에서 하나의 레코드를
: 수정하려고 할 때 발생합니다.
:
: 뉴스그룹을 뒤져보니, 님께서 생각하신 대로 뒤에 들어온 한쪽이 기다리도록 하는 방법에
: 대한 요청이 많던데... 답변은 인터베이스 설계상의 철학이므로 발생하는 에러메시지는
: 그대로 인정하고 잘 처리하는 것이 좋겠다는 내용이 압도적이더군요.
:
: 인터베이스는 락킹 디비가 아니라 버저닝 디비라고 하는군요.
: MS SQL서버의 경우 동시 write 요청에 대해 먼저 들어온 쪽에서 무조건 락을 걸게 된다고 하는데,
: 인터베이스에서는 버저닝을 하므로(각각의 클라이언트는 각각의 '뷰'를 가짐) commit 동작으로
: 실제로 write가 일어날 때가 아니면 데드락은 생기지 않는다고 합니다.
:
: 만약 그리드를 사용해서 레코드를 수정하는 중에 그런 문제가 자주 발생한다면, 그리드에서
: 레코드를 에디트하려고 할 때 새로운 폼을 띄워서 입력하도록 하여 그리드에서 직접 에디트를
: 못하도록 막는 방법도 있겠구요.
:
: 다른 트릭으로는 try~except문으로 해당 익셉션을 받은 후 약간의 인터벌을 주면서 몇번까지
: 재시도해보는 것도 좋을 것 같습니다.
: 3회 정도 실패한 후에는 "다른 사용자가 같은 행을 수정중이므로 수정할 수 없습니다."
: 정도의 메시지를 출력하는 것도 좋겠네요.
:
: 그럼...
:
:
: 하기현 님이 쓰신 글 :
: : Interbase6을 사용하며, 델파이6으로 컴파일했습니다.
: :
: : IB전용 콤포넌트들을 사용하였습니다.
: : IBtransaction의 환경도 네가지 모두 적용해 봤지만
: : 그래도 Read Committed를 사용하니 가장 안정적이더군요.
: :
: : A라는 테이블이 있는데, 두군데의 클라이언트에서
: : 동시에 같은 레코드의 값을 수정하면,
: : 'Lock Conflict on no wait transaction deadlock'
: : 이란 메시지가 뜹니다.
: :
: : 제가 생각할때는 한쪽의 데이터가 수정할때까지 기다렸다가
: : 다른 한쪽이 치고 들어가서 작업을 해줬으면 하는데...
: :
: : 제생각대로 안되나봅니다.
: :
: : 이것을 해결할 방법이 없습니까?
: :