RE: direct read/write to MS SQL from RPG

Understood.

I was pretty sure it wasn't a JDBC limitation since I have done a fair share of Java work as well.

Regards,


Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com

------------------------------

message: 4
date: Mon, 30 Jan 2017 07:36:36 +0100
from: "D*B" <dieter.bender@xxxxxxxxxxxx>
subject: RE: direct read/write to MS SQL from RPG

<Richard>
If you're using ADO.Net or ODBC for your DB interface with the appropriate driver there's no special coding to call stored procedures regardless of database because calls are going through a consistent calling interface regardless of database.

That's how we do it with RPG2SQL. Service program in RPG talks to PC server middleware component which uses ADO.Net/ODBC so developer doesn't really care about SQL syntax. Just needs to know parms to the stored procedure and name to call just like a call/parm.

I would imagine Java and JDBC calls are similar so I would think you could generalize stored procedure calls in your tooling as well.

Different database and SQL syntax yes perhaps.

Different calling conventions. Not se
</Richard>

ArdGate is using JDBC (as it could run on AS/400 without an additional
server) and it's using the ARDPGM interface of DB/2 (so it could provide DB Access with all SQL interfaces of DB2/400).
As a conclusion of this returning ResultSets is not supported by the ArdPgm interface. (this might be circumvented, but is not yet implemented).
For oll other stored procedures parameters might be in, out or in/out. For
DB2 this is declared with the declare procedure statement. From the java perspective you have to register the out parameters, ArdGate sees a statemnet call xyz (:a, :b, :c). For oracle all parameters could be handled as in/out, MS SQL doesn't like this.

D*B