문제의 요지를 다시 짚어보면 다음과 같습니다.
특정 폼(윈도우)에서 입력이 끝나고 레코드가 추가,수정,삭제시 캐쉬 업데이트를 한 후에 차후에 한번에 DB에 적용하는게 성능상 이롭습니다.
특히 C/S가 분산되어 있고 Client가 여러개인 경우에 말입니다.

델파이에서는 쿼리한 검색 결과(client data set, record set등 다양한 용어가 있지만 같은 의미)를 변경할 수 있는 캐쉬 업데이트 기능을 지원해줍니다.
이런 캐쉬에 저장된 데이터를 DB에 적용하는 메소드들도 지원해주고 있죠
이에 대한 자세한 내용은 델파이 관련 서적이나 레퍼런스를 자세히 나와있습니다.

일단 환경적인 부분을 제가 자세히 얘기 않했나 봅니다. 지송 (_ _)
Client는 DB 서버에 하나의 connect만 유지합니다. 즉 Client는 한개 입니다.
또한 분산된 다른 컴퓨터의 DB 서버에 접속하는게 아니라 로컬 DB 서버에 접속하는 방식입니다.
등치있는 DB를 로컬 DB로 활용하고 있습니다. ^^;

어제 이 문제로 오후내내 자료 찾고 주의 사람들한테 물어보고 한 결과 다양한 의견이 나왔습니다.

첫째, 로컬 DB 서버인점과 Client가 하나만 접속하여 사용한다는 점을 고려하여(로컬 컴퓨터 및 단일 클라이언트의 이점) 데이터 변경시(추사,수정,삭제)
즉시 commit 시켜버립니다. 이때 단점은 오픈한 모든 client data set이 닫히므로 다시 오픈해줘야하므로 잦은 데이터 변경시 성능 저하를 초래할 수 있습니다.

둘째, 특정 폼(윈도우)에서 모든 입력을 맞힌 경우에 사용자가 commit 버튼을 클릭하도록 하여 commit 작업을 진행하도록 합니다.
즉 변경된 데이터(캐쉬 업데이트된 데이터)를 DB에 실제로 적용하는 겁니다.
이때 단점은 사용자의 PC가 정전이나 오류로 인해서 다운되었을 때 데이터가 날아갈 수 있다는 것입니다.
그런 예기치 못한 상황을 대비하여 캐쉬 파일로 만들어주는 기능도 지원하지만 프로그램이 복잡해질 수 있습니다.

셋째, client data set이 변경되었으면 DB에 실제로 적용하고 다시 오픈하여 data set을 가져오지 않고 client data set을 그대로 활용하는 방법입니다.
결국 client data set과 DB의 데이터를 동일하게 유지하는 것입니다.
DB에는 캐쉬 업데이트된 데이터들이 적용되는 것이며 다시 쿼리를 요청하여 data set를 가져올 필요가 없으면 필요하다면 다시 가져와도 상관없습니다.
볼랜드 포럼의 델파이 Q&A에 어떤 분이 답변 올려주셔서 알게 되었습니다.
역쉬 매뉴얼을 잘읽어봐야해... ㅠ_ㅠ

기타 서버프로그래밍 하시는 분들도 저런 비슷한 고민 하셨을꺼 같은데 답글이 없더군요 ㅠ_ㅠ
그래서 다양한 의견을 못들어봤습니다. 왜냐면 DB 서버 입자에서 보면 서버프로그램도 Client가 되기 때문에 서버프로그램이 어떤 시점에서 데이터를 변경시킬려고 하는지
그 처리 방안에 대해서 궁금했었습니다. 일단은 서버프로그램이나 DB 응용 프로그램이던지간에 프로그램 성격에 따라 다르게 적용하는게 났지 않냐는 의견도 있었습니다.
(상황에 따라 적절히 대처하자!)

결론은 아무 생각없이 트랜잭션 처리하는 루틴 만들어둬서 적용한게 첫번째 방법인데요 세번째 방법으로 바꾸어서 테스트를 해본 결과 잘동작합니다.
개발툴이나 DB에서 지원하는 기능들을 매뉴얼 잘읽어보고 테스트해봐야겠습니다.

음... 일종의 편법이지만 제대로 동작만 한다면 더없이 효율적인 방법이겠군요.

결국 commit 은 하나의 세션이 종료하는 시점이라는게 항상 정답이겠지요.

DB 서버측에서 에러없이 제대로 동작이 이루어졌다는 보장만 있다면 전혀 문제없이 동작하겠네요 ^^;

답변에 감사드리구요 ^^;

Delphi에서 TIBTransaction 컴포넌트의 메소드 CommitRetaining이 다행이도 세번째 방법을 지원해줍니다.

저도 이 문제 때문에 고민 많이 해서 바꿔 볼려고 했는데 아직 테스트가 덜 되어서 본프로젝트는 붙이지 못한 상황입니다.

정재익님이 말씀하신 데이터 무결성이 보장되는지도 테스트 해봐야겠습니다.