error binding values with 3.1.11 connector/j to server-side prepared statements on mysqld 4.1.12
Posted by: Marc Portier
Date: October 18, 2005 01:47PM

Hi there,

I've recently upgraded my linux distro to ubuntu 5.10 to find it comes with mysqld 4.1.12
which causes a load of problems with the 3.1.7 jdbc driver I was using in most of my apps

I've pinned the issue down to some weird incompatibility in the binding of values to server-side prepared statements...

When inserting the couples (0, "één") (1, "twee") (2, "drie") into a simple table with integer id and string field they end up in the database as (65536, "") (131072, "") and (196608, "")

meaning int-values get transmogrified through some +1 <<16 (i.e. incremented and padded with 2 zero bytes) and string values just get truncated to empty strings.

I've prepared a simple testcase I'm glad to share upon request.
Wondering around with it in different setups I've consistently noticed:

3.0.x drivers work normally with 4.1.12
3.1.x drivers work normally with 4.1.<12
3.1.x drivers fail as described with 4.1.12
3.1.x drivers only work normally with 4.1.12 when adding the property useServerPrepStmts=false to the URL

the mix of setups included driver releases 3.0.14, 3.0.15, 3.1.7, 3.1.11 tested towards
server releases 4.1.10a(both debian and nt) and 4.1.12 (only debian)

haven't tried the 3.1.x with 4.1.>12 combination yet (haven't got access to that)
might be usefull of others could chime in / test out on more recent server releases

If such is deemed appropriate I'll be glad to jot an explanation and the testcase down in some bug-tracking database.

Since the distro packaging updates work like a charm I'ld rather not venture into manually installing other then the provided 4.1.12 server. So I'm kinda hoping things can get solved on the driver side of things.

The useServerPrepStmts=false functions ok as a stop-gap solution, it would be nice though if we could set it through some system wide file rather then per application editing of the connect-url. I was made to believe (by some mix of vague memories and desperate hope) that something like that was already foreseen in the jdbc or driver codebase? Any ideas welcome.

Options: ReplyQuote

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.