JDBC: Prepared statements with more parameters than column names

Question

I'm using the latest version of the JDBC driver - 4.1.5605.100_enu - on Java 1.7, Linux.
I'm connecting to MS SQL Server 2012 Express Edition using a connection URL of the form jdbc:sqlserver://10.0.0.2;user=username;password=pwd;database=testdb1
I have a table with two columns. One is an ID (type bigint) and one is numeric(38, 19).
The following code works exactly as expected:
PreparedStatement stm = connection.prepareStatement("INSERT INTO myTable(id, num) VALUES (?, ?)")
// repeatedly set parameters using setLong, setBigDecimal, then addBatch
stm.executeBatch()
The following code does not work as expected:
PreparedStatement stm = connection.prepareStatement("INSERT INTO myTable(id, num) VALUES (?, ?),  (?, ?)");
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setBigDecimal(4, new BigDecimal("1.234"));
stm.addBatch();
stm.executeBatch();
The code runs normally in the second case, but the second row inserted contains the wrong value in the "num" column - it's been rounded to 1.0 instead of stored as 1.234.
I think this may be because the driver does not understand the types of parameters whose indexes are beyond the number of columns in the insert statement. Running the following code on the second prepared statement:
System.err.println(stm.getParameterMetaData().getParameterTypeName(2)); // prints "numeric"
System.err.println(stm.getParameterMetaData().getParameterTypeName(4)); // fails with IndexOutOfBoundsException
As far as I can tell from the JDBC JavaDoc, this usage is valid and ought to work. Certainly it works as expected (including the parameter metadata) using PostgreSQL and their JDBC driver. Is this a bug in Microsoft's driver?

Answer 1

Hi dtn-cfl,
Thanks for your waiting.
Based on my research(using
SQL Server Profiler to trace DB events), the preparedStatement finally passes the below statements to SQL Server.
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setNull(4, Types.DECIMAL);
declare @p1 int
set @p1=0
exec sp_prepexec @p1 output,N'@P0 bigint,@P1 decimal(38,3),@P2 bigint,@P3 decimal(38,0)',N'INSERT INTO myTable(id, num) VALUES (@P0, @P1), (@P2, @P3) ',1,1.234,2,NULL
select @p1
Pay attention to the @P3 decimal(38,0),  it seems(I don't have access to JDBC source code so that I have to use seem) that the
stm.setNull(4, Types.DECIMAL) will finally parsed as a type decimal(38,0). In SQL Server, to a
decimal datatype，one with smaller scale has a higher precedence. To understand the precedence， please see below code. If you have more interest in data type precedence, you can click
here.
declare @num1 decimal(38,3) --scale 3
declare @num2 decimal(38,2) --scale 2
set @num1 = 3.225
set @num2 = 3.22
select @num1 as num
union all
select @num2
output
num
3.23
3.22
@num1 get rounded to keep the column data type consistency, namely keep the column as type decimal(38,2)
Let's go back to your code, if you would like to make your code work properly, please see below.
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setNull(4, Types.INTEGER);As per the above data type precedence link, a decimal has a higher precedence than integer, so your decimal will not get rounded.
Not only the case in your post, but also any data type inconsistency will lead to the rounding problem. See below.
stm.setLong(1, 1);
stm.setBigDecimal(2, new BigDecimal("1.234"));
stm.setLong(3, 2);
stm.setBigDecimal(4, new BigDecimal("1.2")); // or new BigDecimal("1.23") and any other decimal with different scale leads to rounding problem.
So when you set parameters for a prepareStatement like "INSERT INTO myTable(id, num) VALUES (?, ?),  (?, ?)" with more than one row, you should pay attention to data type consistency fact.
The Microsoft JDBC driver for SQL Server may not be that intelligent, however we can't say that is a bug definitely.
If you have any question, feel free to let me know.
Eric Zhang
TechNet Community Support