Why use SPs?
result
" ...Because stored procedures run in the DBMS itself, they can help to reduce latency in applications. Rather than executing four or five SQL statements in your Java code, you just execute one stored procedure that does the operations for you on the server side. Reducing the number of network trips alone can have a dramatic effect on performance... "
For performance
" ...Using stored procedures has a lot of the same advantages as using application servers based on EJBs or CORBA. The difference is that stored procedures come free with lots of popular DBMSs, while application servers are mostly expensive. This isn't just an issue of license cost. The time it takes to administer and write code for app servers, and the increased complexity of the client applications that rely on them, can be almost wholly replaced by a reliance on your DBMS... "
For simplicity
Are SPs a rival to application servers? I guess so.
What do application servers offer?
Are they just another layer to place shared logic and by doing this to improve performance and re-use?
Certainly the database is still a bottleneck - one whose capacity can be increased and perhaps distributed (with care) over additional resources.
Variations for SQL Server SPs
1. zero parameters (input or output), just an execution facility (no application data in or out)
2. an input parameter, execution can be influenced
3. an output parameter, can have one or more
" ...
CallableStatement toesUp = connection.prepareCall("{ ? = call list_early_deaths () }");
toesUp.registerOutParameter(1, Types.OTHER);
toesUp.execute();
ResultSet rs = (toesUp) getResults.getObject(1);
...Because returning cursors from procedures is not directly supported by JDBC, we use Types.OTHER to declare the return type of the procedure and then cast from the call to getObject()... "
Is it the case input parameters are typed based on the call made when they are set?
However output parameters need to be typed by a call?
Another search on java callablestatement
Result here
"...
The example below creates an instance of CallableStatement that contains a call to the stored procedure getTestData, which has two arguments and no result parameter:
CallableStatement cstmt = con.prepareCall("{call getTestData(?, ?)}");
Whether the ? placeholders are IN, OUT, or INOUT parameters depends on the stored procedure getTestData.
..."
1. Parameters are optional and can be in/out or both
2. Result parameter can only be out (I expect) but is optional
"...
If the stored procedure returns OUT parameters, the JDBC type of each OUT parameter must be registered before the CallableStatement object can be executed..."
3. OUT parameter types must be registered
Problems reading output parameters and results set
"... I have it so that I can either read the resultset values or I can read the OUT parameters, but not both. Unfortunately, my requirement is to read both... "
I think this discussion is saying that you can get a result set that is separate to all output parameters.
I.e. you get your result set as a result of a call to executeQuery()
execute() does not return a result set
- - - -
I know from reading the Java docs on execute() that it can return multiple result sets, which are accessed by separate methods - perhaps output data from a callable statement is returned in two streams, i.e. result sets returned in one stream and output parameters (which could also be result sets) in another.
- - - -
Hmmm... in tests i can call a stored proc
String sql = "{call sp_EM_getWmiLoad}";
The stored proc does the following
select PartnerCountryCd, CountryName from countrycodes
And doing the following code gets access to the results set
ResultSet rs = proc.getResultSet();
I.e. there is NO USE made of parameters yet the output is still accessible