Roman:

I appreciate your prompt response. Would you know how long it takes for
a fix to be put out so that we can download and use it?

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/