Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.
We are being asked to have a .NET SQL Server pgm directly execute a CL pgm on the iSeries. I can think of several ways to try doing this (SQL CALL? Stored Procedure?). But I thought I would ask here to see if any of you have a preferred way of doing this in your shops. The iSeries Access CLI extensions will not be installed on their server - just ODBC connections.
Usually go with Stored Procedure for all the corps I've worked with. But I'm the i-side dude, so I don't deal with the .NET stuff - just the RPG/CL code.
Though sometimes the Stored Procedures are my domain (they're on the AS/400 and .NET folks get scared of computers that don't need to be rebooted every couple hours), where other times I just write the programs and the Stored Procedures are the "web people" thing. As I noted recently, both splits in domain can have issues when uses/reads/modifies SQL DATA comes into play.
Without the iSeries Access CLI stuff they seem to be having problems invoking the Stored Proc. So here's what I'm going to try:
Create a table for them to insert a row with a specified request. Attach a Trigger Pgm to the table to respond to Inserts only. The Trigger Pgm will do the requested Call and will send them a SQL Server trigger file in return (go file) when their results are ready. I'll try this early next week.
do you have a webserver active on the ibmi? You could have the .net program call a webservice/page that would trigger the calling of the "i side commands" you want to do, and then return back the information.
chris
Sounds like a "hack" to me, using a trigger for a a request and response. Can you turn the RPG into a SOAP web service using the IWS? Then .net could consume a SOAP web service. The one drawback (or used to be?) is that the RPG parms are rigid, the client/agent can't send variable length data.
Chris Ringer