임펠리테리입니다.

먼저 업로드한 파일이 다운로드가 되지 않았던 이유... 얼마전에 회사에서 작업중인 프로젝트에 써먹을 생각으로 제 라이브러리에 포함되어 있던 isapi 업로드 함수를 수정했는데, 그 과정에서 한개의 파일만 업로드할 수 있도록 되어 있던 것을 무한정 갯수로 업로드할 수 있도록 고쳤답니다. 덕분에 서버에서 업로드받은 파일들의 이름에 끝에 000, 001, 002, ... 이런 식으로 꼬리가 붙게 되었는데, 제 게시판 DLL에서는 이에 따라 수정을 하지 않아서리 업로드된 파일을 못찾게 되어버렸지요. 시간을 낼 수 있는대로 수정해놓도록 하죠.
업로드를 몇번 반복하는 동안 BDE가 죽어버린 건 아마도 업로드 소스의 버그는 아닐 겁니다. 지금 같은 소스를 수십만 단위의 회원을 가진 사이트에 사용하고 있는데, 몇주동안 아무 이상없이 돌아가고 있거든요. 아마도 제가 다른 프로젝트들을 코딩하고 테스트하면서 계속 BDE를 쓰니까 것때문에 충돌하는게 아닌가 싶네요.
그리고 제 업로드 함수는 어디서 줏어온 게 아니라 거의 3일 가까이 걸려서 제가 직접 작성한 것입니다. 자랑이지만(^^;;) 업로드된 내용을 파싱하기 위해 단 한번도 메모리 할당을 하지 않고 모조리 포인터를 이용한 문자 비교 연산만을 하기 때문에 기존의 어떤 업로드 소스보다도 더 빠릅니다.

그리고, 저도 빌더로 웹서버 프로그래밍을 하는 분을 만나 반갑네요. 정말 드물죠? 하긴 델파이로도 웹서버프로그래밍을 하는 분은 그리 많지 않지만요. 음.. 말씀하신 것으로 보아 이미 어떤 회사에 계신 모양인데, 언젠가 같이 일할 수 있는 기회가 있으면 좋겠네요. 그냥 하는 말이 아니구요.

ISAPI DLL에서 문제가 있다는 말을 여기저기서 보셨다고 하셨는데, 저는 거의 믿지 않습니다. 저희 회사에서는 모든 프로젝트를 ISAPI로만 하거든요. ISAPI DLL이 쓰레드로 돌아간다고 해서 BDE가 뻗어버린다는 말은 좀 무리한 추측이죠. ISAPI의 강점은 역시 로딩속도가 빨라서 결과적으로 리스폰스 속도가 빨라진다는 것, 그리고 동시에 여러 리퀘스트를 받아도 메모리 요구량이 급격히 증가하지 않는다는 점에 있다는 것은 아시죠? 빌더로 작업하면서 만약 CGI로 만들어버리면 엄청난 실행파일 크기와 메모리 요구량 때문에 조그만 사이트에는 몰라도 대형 사이트에서는 무리가 많습니다.
또, DLL로 만들어도 IIS 세팅에 따라 쓰레드가 아니라 별도 프로세스로 만들 수 있습니다. 물론 ISAPI의 원래 목적을 벗어나는 거지만요.

그리고... BLOB 데이터가 많으면 대부분의 디비 서버가 버벅거리는 것은 당연하구요. 그래서 일반적으로 파일등을 저장하기 위한 게시판 등의 웹서버 모듈에서는 파일을 저장하기 위해 디비가 아니라 파일 그대로 파일시스템에 저장하죠. 물론 저도 그렇게 하고 있습니다.

아, 저도 72년생입니다. 제 소개가, 나이가 꽤 많은 것처럼 느껴지던가요? 음.. 영감냄새라도? ^^
그럼 이만...