Date: 2012-10-10 19:59:01 +0200
From: Andy Grove <<andy.grove>>
To: clients devs <>
Version: 11.13.3 (Oct2012)

Last updated: 2012-11-07 19:05:33 +0100

Comment 17788

Date: 2012-10-10 19:59:01 +0200
From: Andy Grove <<andy.grove>>

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4
Build Identifier:

I am running this query using a prepared statement

select a, b, count(*) from foo where c>? group by a, b

a and b are varchars and c is an integer type.

The code:

PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setObject(1, 12345);

This fails with "java.sql.SQLException: EXEC: wrong type for argument 1 of prepared statement: char, expected int"

However, if I change the code to the following then it works correctly:

PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, 12345);

I took a quick look at the source code and it seems that the prepared statement is using the data type for the first column in the select list rather than for the first bound parameter.

Reproducible: Always

Steps to Reproduce:

1. CREATE TABLE foo (a varchar(5), b varchar(5), c integer)
2. INSERT INTO foo VALUES ('a', 'a', 1);
3. Run java code as described in details

Actual Results:

java.sql.SQLException: EXEC: wrong type for argument 1 of prepared statement: char, expected int

Expected Results:

Query should execute without error

Comment 17789

Date: 2012-10-10 20:29:54 +0200
From: @grobian

Changeset d8f8cb98ca1c made by Fabian Groffen fabian@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=d8f8cb98ca1c

Changeset description:

PreparedStatement: fix column offset handling

Since [56ca5fe0526b](https://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=56ca5fe0526b)  we can no longer map a column index directly to our
result array.  Hence, we have to use getColumnIdx() method for each and
every place where we use the column index to lookup something from our
backing arrays.  Thanks Andy Grove in bug #3158.

Comment 17790

Date: 2012-10-10 20:36:16 +0200
From: @grobian

Thanks. I've committed a fix. I think this warrants rebuilding the Oct2012 release. Maybe in the next few days more bugs show up + get fixed.

Comment 17896

Date: 2012-11-07 19:05:33 +0100
From: @grobian

This bug was/is fixed in the Oct2012 release