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