RE: direct read/write to MS SQL from RPG

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 seeing it.

Example welcome if you want to illustrate the problem.

Regards,

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


-----Original Message-----
From: Richard Schoen
Sent: Sunday, January 29, 2017 1:27 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: direct read/write to MS SQL from RPG

Dieter, Not sure I agree with you on stored procedures.

If you're using standard database drivers which I assume you are then the stored procedure layer should be pretty much agnostic and consistent regardless of database driver.

Set up calls to a stored procedure, call it and get data or parm info back.

The SQL difference is in creating the stored procedures, not in calling them.

Maybe you can articulate some use cases where you've had issues ?

Regards,

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

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

message: 1
date: Sun, 29 Jan 2017 17:48:38 +0100
from: "D*B" <dieter.bender@xxxxxxxxxxxx>
subject: RE: direct read/write to MS SQL from RPG

<Justin>

There are some limitations though. The biggest in my opinion is that
you have to disconnect DB2 to access SQL Server.

</Justin>
... then you are doing something wrong! You could have multiple connections at one time and toggle between with set connection.

@stored procedures: stored procedures are not faster, every layer costs some effort - but you would not notice any diffrence. The problem with stored procedures is, that SQL PL is not very portable from box to box, every flavour of SQL has its own dialect (one of the reasons for the limitations of ArdGate with stored procedure support)

Another diffrences between ArdGate and other alternatives: ArdGate is supported by Dieter!!! :)))

D*B