RE: ISTKT & DYNSQL vs. 5722ST1 SQL Development Kit

Last couple of years, it was embedded SQL I coded for a "history data" inquiry 
and report project. It was a little too easy for what I was doing, but I always 
intended to set myself up with SQL CLI for all the reasons Scott listed. That's 
a skill you can use in any midrange shop that has RPG or Cobol or C/CPP. 

My personal bias is to get control close to the "metal". And once you 
understand CLI, you can wrap all the procedures and service programs around it 
you want to, to keep your application coding simple. 

--Alan



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: Saturday, September 09, 2006 3:53 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: ISTKT & DYNSQL vs. 5722ST1 SQL Development Kit



Yet another option is the SQL CLI.  This is an interface to SQL that's 
included with i5/OS (or OS/400) -- it does not require 5722-ST1. It can be 
used from any ILE language including ILE RPG. (and even ILE CL starting 
in V5R3, thanks to CL's *BYVAL support!)

IMHO, it's easier to use and the code is easier to read than the QSQPRCED 
API.

For someone familiar with ILE concepts, it's only a little harder to use 
than embedded SQL.  The only disadvantage is performance, since the 
statements aren't prepared at compile time, only at run-time...   much 
like the PREPARE statement in embedded SQL. But, I've never found the 
performance difference to be very noticable.

Once of the things I really like about the CLI is that it just works.
I'm not constantly fighting with it over the new RPG features.  With 
embedded SQL, I seem to keep running into things that don't work with the 
precompiler. Such as trying to fetch into local variables.  Or using 
nested data structures. Heck, embedded SQL didn't even support free format 
RPG until V5R4.  None of these things were ever a problem with the CLI.

Another thing I like about the CLI is that I can use it to call stored 
procedures and actually read the result set!  AFIAK, it's not possible to 
read a stored procedure's result set with embedded SQL.

But, embedded SQL is a little simpler to code, and does perform better 
especially when you have extremely complicated SQL statements.

Anyway... it's something to think about.