단일 사용자 응용 프로그램이 프로그램을 실행하는 동안 활성화되는 IB 트랜잭션을 하나만 사용하면 부작용이 있습니까? CommitRetaining 및 RollbackRetaining 만 사용합니다.하나의 활성 IB 트랜잭션이 단일 사용자 응용 프로그램의 전체 수명
배경 : IBQuery를 사용하여 모든 레코드를 메모리에 한 번에로드하는 DB Grid (s) (DevExpress)에 연결하려고합니다. 그래서 모든 SQL 삽입 명령 후 모든 데이터를 다시 페치하지 않으려합니다. IBTransaction.Commit은 데이터 집합을 닫습니다.
TClientDataSet을 사용하지 않으려면 데이터베이스 기능을 사용하는 것처럼 들리지만 요즘에는 델파이에서 선호하는 방법입니다. 왜 손에 들고있는 문제에 대한 더 나은 해결책 인 데이터베이스 구성 요소 사용에 대한 더 일반적인 패턴을 따르는 것보다 귀찮은 거래 관행을 사용하고 의심스러운 거래 관행을 사용합니까?
당신은 어딘가에 맞습니다 :) 나는 이미 오래도록 생각하고 있습니다. 직접 TIBQuery 또는 TClientDataset 사용. IBQuery에는 RAD의 개발을보다 쉽게 할 수있게 해주는 좋은 디자인 타임 기능 (예 : SQLUpdate)이 있습니다. 또한 추가적인 레이어가 더 많은 문제를 일으킬 수 있는지, 더 복잡한 것을 만들어 내고 성능을 저하시키는 지에 대한 우려가 있습니다. 사실, 단일 사용자 애플리케이션에 대해 더 나은 선택이 무엇인지 잘 모르겠습니다. 가이드 라인이 있습니까? –
의심의 여지가 없지만, 최소한 피상적 인 수준에서는, 그것을 사용하지 않기 위해'TClientDataSet'을 사용하는 것이 더 복잡합니다. 그러나 일단 사용법을 배우면이 기술을 사용하여 문제없이 해결할 수없는 다양한 문제를 해결할 수 있습니다 (또는 해당 작업을 수행하는 다른 구성 요소가없는 경우). 무료 IB 성능 분석 도구를 포함하여 필자가 작성한 모든 Delphi 데이터베이스 애플리케이션에 대해 'TClientDataSet'을 사용합니다. –
귀하의 정보에 대한 감사합니다 –
CommitRetaining 및 RollbackRetaining이 좋지 않습니다.
거래가 매우 짧아야합니다.
좀 자세히 설명해 주시겠습니까? XRetaining 메소드가 왜 나쁜가요? 왜 거래가 짧아야합니까? 그들이 얼마나 짧아야합니까? –
이것은 구식 버전의 IB에는 해당되었지만 스냅 샷 격리를 사용하지 않는 한 현재 버전에서는 더 이상 유효하지 않습니다. Rob, 스냅 샷 격리를 사용하는 경우 서버는 오래된 레코드 버전을 유지해야합니다. IB 서버의 가비지 컬렉터가 작업을 수행하지 못하도록합니다. 즉, 모든 SELECT가 많은 레코드 버전을 통해 트래킹해야 볼 수있는 버전을 찾습니다. 사용자의 거래로 현재 트랜잭션이 스냅 샷이 아니어도 마찬가지입니다. 이전 버전의 IB에서는 스냅 샷이 아닌 트랜잭션조차도 가비지 수집을 방해합니다. 이것은 몇 년 전에 고쳤다 –
@Craig : 이것이 또한 firebird에도 해당되는지 알고 있습니까? – jachguate
어떤 버전의 Interbase입니까? –
Firebird 2.0을 사용 중입니다 –