저는 처음과 끝이 모두 이상없이 들어갔다가 나오네요.

psql에서 test하신 건가요? 아님 직접 프로그램을 짜신건가요?

전 psql로 했습니다.

디버깅이 버겁지만..

해봤습니다.. ㅠ_ㅠ

에플리케이션(C#으로 짠)에서 입력할때는 439549의 길이값이 나오는데..

데이터베이스에서 char_length(..)로 컬럼의 길이를 알아보면 439412의 길이를 갖습니다.

에플리케이션에서 입력할때의 차이라고는 홑따옴표(')를 (\')로 바꾸어준거 밖에 없습니다.

라고 하는데..

혹시 홑따옴표를 바꾸면서 문제가 생긴것인지 몇가지더 확인해보겠습니다...

아참 pgadmin III는 세이노 컬럼의 내용을 로딩하다가 죽어버립니다 ㅠㅠ

아이고

psql.exe 이놈이 절 싫어하나봅니다...

============================================================

C:\Program Files\PostgreSQL\8.0\bin>psql -u -h 210.110.180.31 -d nms -f sayno.sq
l
psql: 경고: -u 옵션은 권장되지 않습니다. -U 옵션을 사용하세요.
User name: vision
비밀번호:
psql:sayno.sql:1: ERROR:  invalid byte sequence for encoding "UNICODE": 0xe120a3
=============================================================

pgadmin III 요놈도 로딩하다 죽어버리고

psql로도 유니코드 에러 떠버리고

윈도우용 바이너리라 그런지 ;; 유니코드 에러는 어떻게 잡아야할련지요..

쿼리가 실행이 안되니 ㅠㅠ

http://archives.postgresql.org/pgsql-bugs/2004-10/msg00293.php

여기 글을 보면 클라이언트 인코딩이 유니코드를 지원하지 않는다는거같은데..

psql에서 \encoding을 하면 UNICODE가 뜨네요...

상기님,성철님의 옛날 자료를 참조하여 \encoding uhc; 명령을 sql 쿼리 앞에 두고 시작하면

C:\Program Files\PostgreSQL\8.0\bin>psql -u -h 210.110.180.31 -d nms -f sayno.sql

=================

...(생략)

자기 자신에 대하여 전부 까발려야 내가 조언할 것 아닌가
참으로 한심하다. 쯧쯧쯧....
" 추가 인자가 무시되었음
psql:sayno.sql:1: \encoding: "," 추가 인자가 무시되었음
psql:sayno.sql:1: \encoding: "default," 추가 인자가 무시되었음
psql:sayno.sql:1: \encoding: "" 추가 인자가 무시되었음
psql:sayno.sql:1: \encoding: ",'',0" 추가 인자가 무시되었음
psql:sayno.sql:1: \encoding: ");" 추가 인자가 무시되었음

==========

이와같이 실행되며 해당 쿼리는 실행이 되지 않는군요 ㅠ_ㅠ

psql요놈 절 무쟈게 싫어하나봅니다 ㅎㅎ;

으흑;

그나저나 왜 잘리는지 이유를 모르겠군요..

사이즈가 작은 데이터는 아무런 문제가 없는데...아..

계속 찾아봐야겠습니다!

ps.

부산놈이다보니

잘리다를 짤리다 -_- 라고 자꾸쓰네요.. 수정했습니다 ^^;

이거 문제가 점점 커지는것 같습니다...

현재 현상이 제가 문제를 발생 시킨 것이 아니라면(기존의 mssql을 사용할 시 현재 사용하고 있던 API(ADO)로 아무런 문제가 없었습니다..) postgreSQL의 ODBC 프로바이더와 ADO랑 궁합이 맞지 않는다는 결론이 되는것 같습니다.

현재 C#으로 ADO.NET을 이용하여 PostgreSQL을 ODBC로 연결(ODBC프로바이더는 최신버전입니다)하여 클라이언트 프로그램을 만들고 있습니다.

몇가지 메시지를 보내다가 좀 큰 메시지를 보내고 싶어져서 Database에 "세이노 컬럼"을 insert하였으며, 클라이언트 프로그램이 화면을 출력시 뒷 몇줄이 잘려 나와서 db에서의 데이터를 확인해보려 pgadmin III에서 데이터뷰어로 시도하였으나 데이터뷰어가 뻗어버리는 관계로, 데이터를 바꾸었습니다.

데이터의 내용은 이 게시물 에서 바로 윗 댓글까지 이며

데이터를 비교해본 결과 dbms에서는 아무런 문제가 없이 데이터가 들어가 있습니다.

c#어플리케이션 에서 확인 한결과 출력에 사용되는 스트링을 db에서 읽어왔을 때 잘려지는 부분에서 알지 못할 데이터로 깨져버렸군요.

문제는 길이가 작은 데이터의 경우엔 문제가 없는데 왠만큼 길이가 길어지면 이 데이터를 읽어 들일때 깨어지는 현상이 발생합니다.

또한 이 깨어진 데이터 덕분에 odbc쪽 .NET API에서 정의되지 않은 오류도 종종 발생하네요..

으... 좀 상황이 복잡해진것 같습니다 ^^;

자료를 더 찾아 제가 보는 관점이 틀리지 않은지 확인을 해보아야겠습니다.

ADO랑 상성이 안맞으면 M$의 API를 사용하기엔 무리가 있지 싶어서 걱정입니다 ㅠ_ㅠ

테스트 해 보았는데요,

일단 서버차원의 문제는 없는 듯합니다.

그러니까 들어가기는 잘 들어가 있는데 읽어 올 때에 ODBC 드라이버의 문제 때문에 끝이 짤려서 읽혀진다는 것인가요?

제 생각에는 영어로만 되어있는 긴 문서를 입력해 보시구요 역시 같은 문제가 있으면 버그 리포트를 하셔야 할 것 같습니다.

운 좋으면 바로 버그 수정을 받을 수 있습니다.

전 C#은 물론 Windows에서 돌려 본 일이 없기 때문에 test를 못하겠네요. -.-;; 좋은 결과 있기를 바라겠습니다.

네.

혹시나 하여 msdn 에 OdbcDataReader Library 페이지를 열어 둔 것도 테스트 해보았습니다

(쿨럭) 역시나...

버그리포트에 글을 써서 올렸습니다..

(콩글리쉬라 제대로 이해해줄련지 모르겠습니다 ㅠㅠ)

제가 사용한 소스코드와 입력데이터(여기 글 스크랩한 텍스트파일)를 올린 게시물을 링크시켜두었으니 이해가 안가거나 하면 메일로라도 연락이 왔으면 합니다.

아~ 모두들 행운을 빌어주세요 ~

감사합니다 ^^

이런..

bug report에 -- 나와있는 사람들..모두가..

아래의 이유를 되면서 딜레이 시키는군요 ㅠ_ㅠ

The author (Lee Hyun soon <foolbabo@gmail.com>)
 is not a member of any of the restrict_post groups.

흑...

봇인건가 ㅠ_ㅠ;;;

서브스크라이브 가입하고 보냈습니다.

이젠 리턴메일이 안오네요 ㅎㅎ

제대로 간건가 몰겠습니다 ㅠㅠ

아마 스팸을 예방하려고 그랬을겁니다.

좋은 결과 있기를 바라겠습니다.

어제 올려 pgsql bug mailing List에 올려 놓고 기다리고 있습니다..

음.. 한번 오타를 써서 한번더 놓았네요 ...

혹시나 하여 메일링 리스트에 링크(소스프로그램, 인풋데이터)를 걸어놨는데.

한명도 안봤네요 ㅠ_ㅠ

일단 기다리는 동안

프로젝트는 쭈욱 ~ 계속 되어야 하므로..

text형 필드에 데이터를 읽어올때 한계치를 찾아봤습니다..

현재 한글은 2121, 영어 2106바이트까지 아무런 문제 없이 입력/출력이 되네요..

대충잡아 안정권은 2000바이트라고 보는것이 나은것 같습니다.

자식 테이블 하나 더 만들어 외래키 하나 잡아서

합치는 방식으로 2000바이트 이상의 데이터를 입력/출력해야겠습니다...

pgsql bug mailing list에서 개발자의 답변을 기다리며..