Hi,
> when I call code residing in SAP DB, that is DBPROCs, what options
> do I have to reduce calling overhead? I'd guess:
>
> 1. pack multiple invocations into one wire packet ("BULK CALL")
> 2. make a single invocation with "structured array data" as In/Out
> parameter ("Stream")
>
> Browsing through docs/code, I found some hints what specific SAP DB
> features could do above .. but more questions are left and hints
> would be welcome:
>
> MASS CMD with DBPROCs
SAP DB supports 'mass commands' only for insert/delete/update
(and also select, but these are not shown in JDBC). If such a command
is executed in a PreparedStatemen via the addBatch() - executeBatch()
sequence, the capability of these commands is honored. (The mass command
is more something like option 2 you have guessed - one command and
a parameter array appended)
This kind of execution is not supported for any other command, including
a DB procedure call.
In the SAP DB 'wire' protocol, there is also the possibility of sending
multiple separate commands within one packet. For JDBC batch execution
of Prepared/Callable statements we don't do this currently (It is done
this way for normal Statements).
If a command is executed with executeBatch() it will be executed in a
loop until all data has been processed, which may be of course less loops
if it is a mass command that can process more than one set of input parameters
with one call.
> ABAP Tables and LC Streams
>
> ABAP Tables and LC Streams as In/Out parameters in C++ LC procedures.
> Is this exclusively supported by the C/C++ SQL precompiler or also
> available as some proprietory ODBC extension (that is, at API
> call level)?
> My understanding was, that ODBC is supposed to be the "native" call
> level API to SAP DB. But if it doesn't support advanced features, then
> one has to use the precompiler or go down to the wire protocol level?
The ABAP tables/LC streams are a special feature of the precompiler, and are only
available there, and they are also only of use in that C++ based DB procedures,
not in normal statements.
> Btw. at least for JDBC, Oracle has done something very nice to support
> REFCURSOR parameters (similar to ABAP tables / LC streams) from JDBC.
> They simply defined another bind variable type (OracleTypes.CURSOR)
> which can be handled like another ResultSet after binding:
Have you read about Procedures returning a result set (RETURNS CURSOR clause)in the
documentation?
http://www.sapdb.org/7.4/htmhelp/a7/41ee11605911d3a98800a0c9449261/content.htm
If you have such a procedure, a call will return a result set (Available through the
usual
standard Statement methods, without any propietary wrinkles in the Java part.)
Regards
Alexander Schr�der
SAP Labs Berlin
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
