Re: Embedded SQL - Dumb Question probably

[qsrvbas@xxxxxxxxxxxx]

Tom Liotta wrote:
>    8. RE: Embedded SQL - Dumb Question probably (Shannon ODonnell)
>
> Is it an N/C item that comes on the LPP CD's?  I can install it myself if
> that's the case, but otherwise, I'll have to order it.

Shannon:

It is chargeable. It's been a very long time since I've seen 
anything on the cost though. I don't recall it being much for 
lower-tier systems. (And I always thought that a small development 
system, possibly even a used one, is a great way to reduce 
upper-tier development costs because of that.)

As mentioned elsewhere, it should be on distribution CDs and 
available for a grace period.

Joe mentioned a kind of 'reverse engineering' through perhaps the 
use of RPG compiler listings from the pre-processed code. I seem to 
recall trying something once to see if it was feasible but ran into 
an error from a missing SQL object or similar. I assumed that one or 
more of the generated CALLs targeted SQL APIs that either were not 
installed or were triggering a test against an LPP requirement. It'd 
be interesting to see something work, but I'm not sure how it might 
be demonstrated to others. I don't know details of the licensing. In 
any event, I had more than enough to keep me busy and never pursued 
it farther. And you'd have to have the pre-processor working first 
in order to have direction.

SQL CLI is always a possibility. The relative complexity of coding 
for SQL CLI compared to simple embedded SQL is what is paid for most 
of the time. AFAIK, there should be a performance boost also, though 
I haven't needed to do SQL CLI in a performance-critical job.

Tom Liotta

> -----Original Message-----
>
> Shannon ODonnell wrote:
> >    8. RE: Embedded SQL - Dumb Question probably (Shannon ODonnell)
> >
> > There's a thought. Is that required for embedded SQL?
>
> I get digests of the RPG list, so you might have gotten a hundred other
> responses by the time this hits the list -- they haven't reached me yet.
> Still, it's late in the work day, so I might as well add my $.02 into the
> pot.
>
> In a very practical sense, the SQL _Development_ Kit is little more 
> than the
> pre-processor for embedded SQL. That's what allows... ummm...
> "development" of SQL applications.
>
> True, there's more to it than that. However, processing the embedded 
> SQL to
> enable compiling the programs is the biggest bang-for-the-buck out of 
> it for
> most of us.