aspose file tools*
The moose likes JDBC and the fly likes Number of parameters in CallableStatement is less than the number of arguments in SP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Number of parameters in CallableStatement is less than the number of arguments in SP" Watch "Number of parameters in CallableStatement is less than the number of arguments in SP" New topic
Author

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

Vijay Rajaram
Greenhorn

Joined: Nov 17, 2003
Posts: 12
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.



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.



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
Bartender

Joined: Dec 20, 2006
Posts: 2503
    
    8

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



OCUP UML fundamental and ITIL foundation
youtube channel
Vijay Rajaram
Greenhorn

Joined: Nov 17, 2003
Posts: 12
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
Ranch Hand

Joined: Oct 06, 2007
Posts: 338
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
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187


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
Ranch Hand

Joined: Oct 06, 2007
Posts: 338
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Number of parameters in CallableStatement is less than the number of arguments in SP