Subject | Re: Fwd: FireBird JCA-JDBC driver character encoding bug [redcat@chnu.cv.ua] |
---|---|
Author | rrokytskyy |
Post date | 2002-08-21T22:19:31Z |
Hi,
It seems to me that I have fixed that bug. At least I use the same
mechanism of converting String to a byte[] as in FBStringField.
However, I was not able to create a test that cleanly shows that
problem is gone (I have problems reproducing the bug). The whole test
suite runs fine on my machine.
Please update your sources and try it yourself.
Best regrads,
Roman
It seems to me that I have fixed that bug. At least I use the same
mechanism of converting String to a byte[] as in FBStringField.
However, I was not able to create a test that cleanly shows that
problem is gone (I have problems reproducing the bug). The whole test
suite runs fine on my machine.
Please update your sources and try it yourself.
Best regrads,
Roman
--- In Firebird-Java@y..., "rrokytskyy" <rrokytskyy@y...> wrote:
> Hi,
>
> Yes, this is a bug. :( But I'm not sure if it will be easy to
> correct. It happens only if a national characters are hardcoded in
> the SQL statement itself:
>
> PreparedStatement stmt = con.prepareStatement(
> "INSERT INTO a_table VALUES('my national string', ?)");
>
> If passed as parameter into PreparedStatement using setString(int,
> String), everything will be ok. It also affects Statement instances.
>
> I will check it, it seems to be easy to correct by checking value of
> lc_ctype in DPB. But I'm not sure if we have access to DPB in the
> places where XdrOutputStream is used.
>
> Best regards,
> Roman