MySQL Bugs: #4138: Connector/J 3.0.14 returns Type.OTHER (1111) for usigned integers

Bug #4138	Connector/J 3.0.14 returns Type.OTHER (1111) for usigned integers
Submitted:	15 Jun 2004 8:56	Modified:	3 Aug 2004 0:17
Reporter:	johan compagner	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / J	Severity:	S2 (Serious)
Version:	3.0.14	OS:	Any (all)
Assigned to:	Mark Matthews	CPU Architecture:	Any

Description:
in the connector driver 3.0.11 everything was ok. an unsiged integer returned normally as a Types.INTEGER (or Types.SMALLINTEGER) ect.

But in the latest driver (3.0.14) unsiged values are suddenly all Types.OTHER (1111) Why is that? They are just integers as far as i know..

How to repeat:
read the meta data.

and you will get:
Column name product_id type 1111 lenght 11 is_nullable NO

Suggested fix:
refert to 3.0.11 behaviour

From what method are you extracting this metadata? DatabaseMetaData.getColumns() or ResultSetMetaData methods?

We go through the DatabaseMetaData.getColumns() where we see the error first. But we are also using result set meta data so that we know what call we have to make to get the right value out of the resultset. I currently don't know if that also does goes wrong.

What is the process of this bug?
We have customers that are using mysql for there solution and they can't go on because of this.

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

Thanks for your bug report, this will be in 3.0.15 (you can grab a snapshot build after 00:00 GMT this evening from http://downloads.mysql.com/snapshots.php).

One hint, providing an _full_ testcase when reporting bugs usually gets these things resolved much quicker, as less engineering time is spent creating one, and making sure it 'jives' with the problem you're reporting. You might consider providing one in future bug reports if  you have the ability to do so.