firebird 를 활용하고 있다. 무료이고, 사용에 제한이 없는게 가장 큰 장점이라고 하는데.., 사실은 제일 먼저 접한 디비이고 다른 거는 사용해 본적이 없기는 하지만, (원산지증명 관련 프로그램개발을 하고 있다는 어떤 프로그래머의 얘기로는 select * 가 다른 디비에 비해 무척 빠른 디비라고 하는데.. 만일 그게 팩트라면 나의 필요에 무척 적합한 디비이다.) 아마 다른 db 들도 크게 다르겠나.. 암튼,

db 를 사용하여 분석툴을 만들다 보면 데이터 구조의 정의를 필요에 따라 실시간으로 바꾸어 사용하게 되기 때문에 필연적으로 만날 수 밖에 없는 문제상황이다.

unsuccessful metadata update... table ..... too many versions..

이게 나타난 이유는 데이터를 설계하고.. 이후에 추가하거나 삭제를 할 경우 firebird 는 TABLE 당 256 번까지만 허용하고 있다. 해결책으로 firebird 홈페이지(FAQ)에서는 backup 과 restore 를 해주라는 것인데, 이 방법말고, 실시간으로 해결할 수 있는 방법이

RDB$FORMAT 의 값이 255 개인지를 점검을 해서 추가적으로 갱신해야할 것을 포함하여 255 개 이하이면 갱신을 하고 255개 이상이면 기존 table 을 DROP 후 새로 CREATE 를 하는 것이다.

이렇게 만들면 아마도 필연적(?) 만나게 되는 두번째 문제상황이 있는데, 실시간으로 table 을 drop 할 때, 어쩌면 만날 수도 있는 문제상황으로(물론, 만나지 않을 수도 있고(테이블 설계할 때 삽입 삭제등의 sql문장을 일단 clear 해 놓는 습관을 갖고 있었다면)).. 이게 create 에서는 안나타나고 drop 할 때만 나타난다.

unsuccessful metadata update.. table ..... is in use 이다.

commit 을 해버리면 문제가 아니지만 commitretaining 을 할 때가 문제이다. commit 을 해 버리면 기존에 갖고 있던 모든 연결을 몽땅 해제해 놓으므로 분석중에 있는 과정에서 다시 재 연결해야 하고 몹시 번거롭게 된다. 대개 삽입삭제 등 일반적인 sql 문장은 별도 컴포넌트들에 설정해 놓고, 데이터구조의 갱신은 또 다른 컴포넌트들을 사용하기 때문에 발생하는 것이고.. 이러한 상황을 알면 매우 간단한 문제인데.. 이걸 눈치채기가 .. 만만치 않더라. in use 라니 난감하지.. 아무튼 해당 테이블과 관련된 기존에 정의해 놓은 sql 관련 문장을 모두 clear 해 놓고 commitretaining 을 하면 깔끔하게 문제가 해결된다.