Re:SQL on AS400 was(Modernization and multi-member files)

Folks

Embedded SQL and a pre-compiler are not specific to the iSeries - they have been around for a long time. Why, you can actually use DECLARE CURSOR and OPEN and FETCH in SQL Server code if you want to - that is embedded SQL.

Vern

-------------- Original message --------------
From: Frank.Kolmann@xxxxxxxxxx

Jon
It was I who used the incompetant word, not Nathan.

I have no idea what SQLCLI is and have never used it.
Originally SQL (or should I call it embedded SQL) was a separately
purchased product. Without this product I found the SQL-like
interfaces (OPNQRYF, QRYMGMT) etc. very cumbersome.

When the company purchased BPCS they got 57xx-ST1 LPP.
It is this product that I see as SQL.
Perhaps the SQL precompiler is a legacy of this separation of
the imbedded-SQL into a separately purchased product.
There is the 'native' for want of another word, access to the
AS400 database and there is SQL. They coexist. If the
S/38 had only SQL as a database access method I reckon no one
would have adopted it.

I have always had small issues with the SQL precompiler,
using different compile commands, different parameters on the commands.
It seems that to make the 2 data base access methods available
on a common compiler is next to impossible.

But surely WDSCi can be fixed to have SQL variables in the Outline View.
Is this not a level of competency.

Frank Kolmann


Message from Jon Paris on Fri, 18 Jul 2008
11:30:44 -0400

On 17-Jul-08, at 8:49 PM, Nathan Andelin wrote:

THE ENTIRE IMPLEMENTATION of SQL on the AS400 smacks of incompetence
and I believe it was not ROCHESTER that was responsible, but rather
the
influence of the 'big-iron' in TORONTO.
(rant rant rant) apologies

First of all I don't agree with Nathan's "incompetence" remark - I
have had many issues - particularly with the pre-compiler but
"incompetent"? Anyway there are two things fundamentally wrong with
this particular argument ...

First, you can't hang this one on Toronto. DB/2 for the i is a home
grown Rochester product and that in part was why it lagged behind the
other DB/2 implementations for so many years. They could not take
advantage of the DB/2 Universal code base for enhancements to SQL. I
believe that these days they may be able to pick up some of the DB/2
code from Toronto but that is a relatively recent thing.

Not that Toronto Lab (under the Software Group and lately Rational)
haven't done some monumentally dumb things related to "i" - but let's
at least criticize them for what they _have_ done!

Jon Paris

www.Partner400.com
www.SystemiDeveloper.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.