Roman:

I went through the following steps in sql:

Alter table MARC_TO_UCS2
alter MARC_FINAL_CHARACTER type varchar(2);
commit;

CREATE TABLE "MARC_TO_UCS2_TEMP"
(
"US_MARC" DECIMAL(1, 0) DEFAULT 0 NOT NULL,
"UNIMARC" DECIMAL(1, 0) DEFAULT 1 NOT NULL,
"MARC_FINAL_CHARACTER" VARCHAR(2) NOT NULL,
"MARC_CODE_POINT" VARCHAR(8) NOT NULL,
"UCS2_CODE_POINT" VARCHAR(8) NOT NULL,
"DESCR" VARCHAR(80)
);


INSERT INTO
MARC_TO_UCS2_TEMP(US_MARC,UNIMARC,MARC_FINAL_CHARACTER,MARC_CODE_POINT,U
CS2_CODE_POINT,DESCR) SELECT
US_MARC,UNIMARC,MARC_FINAL_CHARACTER,MARC_CODE_POINT,UCS2_CODE_POINT,DES
CR from MARC_TO_UCS2;

delete from MARC_TO_UCS2;

INSERT INTO
MARC_TO_UCS2(US_MARC,UNIMARC,MARC_FINAL_CHARACTER,MARC_CODE_POINT,UCS2_C
ODE_POINT,DESCR) SELECT
US_MARC,UNIMARC,MARC_FINAL_CHARACTER,MARC_CODE_POINT,UCS2_CODE_POINT,DES
CR from MARC_TO_UCS2_TEMP;
delete from MARC_TO_UCS2_TEMP;
commit;
drop table MARC_TO_UCS2_TEMP;
commit;

Effectively, I am reading information from the original table, saved it
to a temporary table where the data type is declared varchar (I assume
any space I have read would be stripped off when the data is saved in
the temporary table), deleting all rows from original table, and
recopying data from the temporary table to original table.

After doing this, I had exactly the same problem as I had before -that
is a space was appended to the original string. Incidentally, when I
accessed the data with Interbase driver, it seemed to work fine.

Prabhakar Krishnaswami

Software Engineer



Dynix

pkrishnaswami@...

p 801-223-5817

f 801-223-5202

www.dynix.com


-----Original Message-----
From: Roman Rokytskyy [mailto:rrokytskyy@...]
Sent: Wednesday, August 13, 2003 3:21 PM
To: Firebird-Java@yahoogroups.com
Subject: [Firebird-Java] Re: Unnecessary padding to Strings read

Hi,

> The data type declared in the Unicode database was char[2]. The
> value of 40 was stored in the table. Would you still pad it since
> the length of the value matches the data type size?

Driver does not pad the string, database server does this. However I
confirm your report.

> Now I changed this once to varchar[2] and another time to varchar[6]
> using alter command but in both the cases, the behaviour was the
> same.

This will not help since data stored in the column are already padded.
Changing to VARCHAR will not trim the column.

> Incidentally, is this only an issue in Unicode databases and
> not regular databases?

Seems to be a bug in the server. I will report it to the developer
list. Reason is that unicode columns computes maximum length of the
column assuming that each character will use 3 bytes per character
(CHAR(2) has size to store 6 bytes). However, UNICODE_FSS uses
variable size characters, and in case of "40" will use only 2 bytes,
rest 4 bytes are padded with spaces.

> In regular databases, when this field value is read what I see in
> the debugger was "40" but in Unicode databases the value read is
> "40 ";

In "regular" database character encoding is most likely "NONE" which
means that one character uses only 1 byte. In this case padding works
correctly.

Best regards,
Roman Rokytskyy



To unsubscribe from this group, send an email to:
Firebird-Java-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/