I just loaded it on the system from the LPP CDs yesterday. They are
purchasing a new system within 30 days and they said they'd just pay for the
license then.
That problem is solved.
It's funny, you get on someone else's system and you start doing stuff and
you don't even think about them not having the software you have used for
years. You just assume everyone would have things like SQL Dev Kit and the
System Openess Includes installed now (which by the way, I also had to
install on their system). That's what happens though when you assume things
from a developers viewpoint instead of the viewpoint of that particular
business' needs.
Thanks everyone!
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of qsrvbas@xxxxxxxxxxxx
Sent: Thursday, July 26, 2007 11:37 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Embedded SQL - Dumb Question probably
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.
--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788 x313
253-479-1416
Fax 253-872-7904
http://www.powertech.com
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
