Number of parameters in CallableStatement is less than the number of arguments in SP

[Vijay Rajaram]

Database: MS SQL Server
Java: 1.6

The stored proc which my frontend would use has 3 input parameters with default values (NULL) for all 3 parameters.

  
CREATE PROCEDURE search_profile(
@login_id varchar(20) = NULL,
@password varchar(50) = NULL,
@name varchar(50) = NULL)
AS
BEGIN
SELECT * FROM profiles 
WHERE login_id = ISNULL(@login_id, login_id)
AND password = ISNULL(@password, password)
AND name = ISNULL(@name, email) 
END

But my frontend would use just only 1 parameter out of 3. For this I have my JDBC code like this using the named parameter feature.

    
CallableStatement callStmt = dbConnection.prepareCall("{CALL search_profile (?)}")
callStmt.setString("name", "John");
 
ResultSet resultSet = callStmt.executeQuery();

I get an error "The index 3 is out of range."

This JDBC code works fine if I pass all 3 parameters (or) if I pass only the first parameter login_id. I don�t think the JDBC CallableStatement requires same number of parameters as the backend strored proc.

[Jan Cumps]

It might work if you set the unused parameters to SQL NULL.

CallableStatement callStmt = dbConnection.prepareCall("{CALL search_profile (?, ?, ?)}");
callStmt.setString("name", "John"); 
callStmt.setNull(<look this up in the API>);
callStmt.setNull(<look this up in the API>);
ResultSet resultSet = callStmt.executeQuery();

[Vijay Rajaram]

yes, that would work but that is not what I want to do. Reason: What if someone adds a new argument in the stored proc? The stored procs are usually used by many people in real time. And for some requirement they would need a new argument (of course with default value) added to the proc.

[Paul Campbell]

Originally posted by Vijay Rajaram:
yes, that would work but that is not what I want to do. Reason: What if someone adds a new argument in the stored proc? The stored procs are usually used by many people in real time. And for some requirement they would need a new argument (of course with default value) added to the proc.

if your intention is for your default value to be null... your procedure will never return a value unless all arguments are supplied... in SQL null can never be compared to anything.

[Jimmy Clark]

What if someone adds a new argument in the stored proc?

They shouldn't change this stored procedure, they should create a new one that matches their requirement.

What if someone deletes the stored procedure?

What if someone changes the name of the stored procedure?

What if someone changes the SQL statement in the stored procedure?

I'm sure there are a few more "what ifs" that may apply. What you have to decide is how many "what ifs" will you attempt to handle with the Java code?
[ December 23, 2008: Message edited by: James Clark ]

[Paul Campbell]

Originally posted by Vijay Rajaram:
yes, that would work but that is not what I want to do. Reason: What if someone adds a new argument in the stored proc? The stored procs are usually used by many people in real time. And for some requirement they would need a new argument (of course with default value) added to the proc.

SQL procedures support overloading.
[ December 24, 2008: Message edited by: Paul Campbell ]