Out of Memory 나는 것은 어디에선가 Memory Leak이 일어난다는 것인데요...
굳이 타이머가 아닐 수도 있으니 CodeGuard를 켜 놓고 몇 분 동안 운용한 뒤 종료하여
누수 지점을 알아보거나 FastMM 과 같은 컴포넌트를 이용하여 TRACE해 볼 수 도 있겠네요.

저 또한 이런 Out of Memory를 만난 적이 있었고.. 나중에 밝혀냈지만,..
저 구석의, 생각지도 않은 상위 클래스에서 사용하는 함수에서 메모리 누수가 있더군요.
코드 어디에선가 계속 세고 있다는 것입니다.

그리고, 타이머를 이렇게 쓰는 것은 개발자마다 호불호가 있겠지만
3초 타이머 시간 + 프로세싱 타임  + 3초 타이머 + ... 이런 식으로 계속 누적되어지면
정확히 3초가 지켜지지 않고, 며칠 상간에 1~2초씩 늦추어지는(프로세싱 타임이 계속 누적되어서)..현상이
발생하는데요... 정확히 3초를 지키지 않아도 되는 것이라면 괜찮겠지만,
3초가 다른 프로세서와 연동되어서 정확히 지켜야 되는 타이밍이라면
문제가 될 수도 있을 것 같네요.

UniDAC의 Connection Pool 메카니즘이 어떻게 되어있는 지는 잘 모르겠는데,
보통 Connection Pool은 몇 개의 Connection을 미리 가지고 있다가 요청에 따라
하나씩 주는 것이라.. 말씀하신 것으로 보면 매번 DB Connection open/close를 하지는
않는 것 같은데,
만일 계속 3초마다 DB Connection을 새롭게 open / Close하면 그것도 상당한 overhead일 것 같네요.
3초마다 계속 읽어서 표시해야 할 것이라면 지속적으로 DB Connection을 유지해도 좋을 것 같네요.

꼭 찾아내시길..

그럼 이만.

하안인 님이 쓰신 글 :
: 타이머내에서
:
: Timer1->Enabled = false;
:
: try
: {
:  //작업
: }
: __finally
: {
:      Timer1->Enabled = true;
: }
:
: 로 코딩하였구요.
:
: DB접속은 devart 의 UniDAC 컴포넌트를 사용해서 오라클에 접속합니다.
: UniDAC 에 두가지 옵션이 있는데
: Connection을 유지해서 작업하는 것이 있구요.
: Connection을 pooling 을 true로 해놓으면 connection 속도가 빨라서
: 그때 열고 끝나면 닫을 수 있도록 되어 있어서 사용했습니다.
:
: 위의 타이머 구조에서 문제가 있을 수 있나요.
:
:
: 돌맹이 님이 쓰신 글 :
: : 혹, 3초에 한 번씩 수행하는 작업이 3초를 초과하는 경우가 있지 않을까요?
: : 간혹 이렇게 다음 이벤트가 발생할 때까지 수행 이벤트가 끝나지 않으면,
: : 이런 상황이 중첩되다 보면 이런 상황으로 도달하는 것으로 알고 있습니다.
: :
: : 3초마다 계속 DB 접속을 새로하는 것 같은데,
: : 한 번 접속 후 계속사용하는 것으로 해도 되지 않을까요? 너무 많은 오버해드가 있을 것 같네요.
: : 만약 작업이 오래 걸리면 이 작업은 스레드로 빼고, 타이머 이벤트에서는 스레드에 이벤트만
: : 던져주는 방식으로 수정해도 괜찮을 것 같네요.
: :
: : 도움이 되셨기를...
: :
: : 하안인 님이 쓰신 글 :
: : :
: : : c++buider6.0을 사용하고 있습니다.
: : :
: : : 타이머를 작동해서 3초에 한번씩 데이타베이스에 접근해서 퀴리한 후
: : : 데이타베이스를 닫고 종료한후 다시 타이머를 가동해서
: : : 반복적으로 일을 수행합니다.
: : :
: : : 그런데 1~3일정도 프로그램을 실행하면 out of memory 메시지가 나오네요.
: : :
: : : 변수를 메모리를 할당하지도 않고
: : :
: : : 퀴리를 돌려서 사용하는것 밖에 없는데요.
: : :
: : : 어떤 것을 봐야 할까요?
: : :
: : : 감사합니다.