Tobias Oberstein wrote :
>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
>The docs about the application level protocol used between clients
>and SAP DB tasks talks about "MASS CMD". Multiple rows may be
>transmitted in one package for INSERT/DELETE/UPDATE and also SELECT
>for reasons of efficiency ("ODBC SQLBulkOperations"). Is it possible
>to use this also to call DBPROCs with mass sets of IN parameters or
>is it unavoidable that every DBPROC CALL results in a network round-trip?
Sorry, this is not possible for DBPROC calls.
>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?
This is a C/C++ SQL precompiler feature, which is not supported
by other embeddings.
>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:
>import oracle.jdbc.driver.*;
>...
>CallableStatement cstmt;
>ResultSet cursor;
>// Use a PL/SQL block to open the cursor
>cstmt = conn.prepareCall ("begin open ? for select ename from emp; end;");
>cstmt.registerOutParameter (1, OracleTypes.CURSOR);
>cstmt.execute ();
>cursor = ((OracleCallableStatement)cstmt).getCursor (1);
>// Use the cursor like a normal ResultSet
>while (cursor.next ())
> {System.out.println (cursor.getString (1));}
For normal db-procedures (those not written in C++) you can define
that a procedure returns a cursor. In that case the java access is
very similar to your oracle example.
For C++ db-procedures this feature is not avaiable, since we haven't
had the requirement yet.
Best Regards,
Thomas
--
Thomas Anhaus
SAP DB, SAP Labs Berlin
[EMAIL PROTECTED]
http://www.sapdb.org/
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general