Wrong string length from unicode database in Borland's app

[Alex Guryanow]

Hi,

I have windows app written in Borland C++ Builder 5.0. Using ODBC
driver windows app connects to database on linux server. Database is
created with UNICODE encoding.

When pg-server is version 7.1.3 windows app works fine, but when
pg-server is version 7.4.6 or 8.0beta4 under certain conditions the
app receives strings with wrong lengths. For example: the database
contains table "issue" with the following structure:

Column | Type | Modifiers
-----------+--------------------------+---------------
id | integer | not null ...
mag_id | integer |
year | character(36) |
volume | character(78) |
number | character(300) |
user_name | character(20) | default getpgusername()
mod_date | timestamp with time zone | default now()

Only the column "volume" can contain unicode symbols.

When the the windows application executes the following query:

select year, trim(number) from issue where mag_id = 25403;

all works fine. But by executing the query

select volume, trim(number) from issue where mag_id = 25403;

the datagrid component (that displays query's results) contains in
second column values with length of 32769. Those big values are only
in rows where appropriate "volume" field contains unicode symbols.
Actually all values in column "number" are 5-7 symbols long.

By executing the query

select year, number from issue where mag_id = 25403;

all works fine.

I have checked several versions of ODBC-driver: 07.03.0200,
07.05.0001, 08.00.0002 - the effects are the same: all works fine with
postgres-server 7.1.3 and works bad with 7.4.6 or 8.0beta4

Changing of driver settings (as described on
http://gborg.postgresql.org/project/...bc/faq/faq.php in "Borland
Apps" section) does not help too. My setup is:

Parse Statements - checked
Unknown Sizes - Longest
Text as LongVarChar - checked
Unknowns as LongVarChar - unchecked

Without those settings the windows app works even worse.

Please help me to solve this problem. May be I'm doing something
wrong? May be my windows is set up incorrectly? (I'm using Win2K SP4)
Or is this a ODBC-driver's bug? Or server's? Or may be it's a Borlands
BDE error?

Has somebody used windows app written in borland to connect to
unicode table under postgresql > 7.1.3 ?
Best regards,
Alex
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

Alex Guryanow <ga*@nlr.ru> writes:

When pg-server is version 7.1.3 windows app works fine, but when
pg-server is version 7.4.6 or 8.0beta4 under certain conditions the
app receives strings with wrong lengths.
Are both servers set up with the same database encoding? (Is the 7.1
server even compiled to support non-ASCII encodings?)
But by executing the query
select volume, trim(number) from issue where mag_id = 25403;
the datagrid component (that displays query's results) contains in
second column values with length of 32769.

If you try the same query in plain psql, what do you get? What is in
the wrong-length value, exactly?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Alex Guryanow]

TL> Alex Guryanow <ga*@nlr.ru> writes:

When pg-server is version 7.1.3 windows app works fine, but when
pg-server is version 7.4.6 or 8.0beta4 under certain conditions the
app receives strings with wrong lengths.
TL> Are both servers set up with the same database encoding?

I think the answer is yes. For both servers the command "initdb" was
executed only with parameter DATADIR. At the same time the locale is
set up to "ru_RU.cp1251".

But by creating the database I specify parameter "-E UNICODE" and
"psql -l" shows that the database is in UNICODE encoding. One
time I have forgotten to specify '-E UNICODE' by executing createdb
and windows app worked fine with 7.4.6
TL> (Is the 7.1
TL> server even compiled to support non-ASCII encodings?)

Here is the fragment of config.status from 7.1.3 source directory

../configure --prefix=/db/pgsql-713 --enable-locale --enable-multibyte --with-perl

But by executing the query
select volume, trim(number) from issue where mag_id = 25403;
the datagrid component (that displays query's results) contains in
second column values with length of 32769.

TL> If you try the same query in plain psql, what do you get?

I get all ok. For example, the query

select volume, length( trim( number ) ) from issue where mag_id = 25403;

shows in second column values from 5 to 7

TL> What is in
TL> the wrong-length value, exactly?

'N 1-2'

The appropriate "volume" column contains 'Evf. 120' where 'E' is 'E
with ascent' (I don't know how to write them in this letter). pg_dump
writes the following sequence of bytes (in hex-format) for this value:

C3 89 76 66 2E 20 31 32 30

and 'N 1-2' is

4E 20 31 2D 32
Best regards,
Alex
TL> regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org