× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



DB2 for i5/OS sticks to ANSI SQL primarily to maintain compatibility with
DB2 LUW & DB2 for z/OS. They want IBM customers to be able to port SQL
applications without worrying about incompatibilities between different IBM
database platforms.
I personally would wish they don't have to be such stickler to ANSI SQL...
so many opportunities out there (i.e. my wish list includes making views
keyed since we already have keyed LFs).

Based on that, it looks to me that ASC programmers must have their own
parsing routines. I can't tell for sure as I am unfamiliar with Sequel's
internals. Long time ago I heard that they used to rely on QQQQry API for
execution, but recently someone mentioned they don't necessarily do that any
longer.
As you said, best to go to the source and ask them.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i5/OS and OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: RE: RPG vs SQL

Elvis,

Many thanks for posting that link on SQL joined updates. Our shop has used
ASC's "Sequel" product for a decade or more and I thought I was getting
fairly good at SQL - blithely assuming that the differences between Sequel
and standard SQL were trivial ones of syntax.

The article shows, however, that standard SQL requires a rather
non-intuitive syntax for joined UPDATE statements, i.e.: you can't just wrap
a "FROM TableA a INNER JOIN TableB b ON a.key_field = b.key_field" with an
UPDATE/SET and expect it to work correctly.

The article mentions that SQL Server's T-SQL extensions do allow the JOIN
to be inside the FROM but that standard SQL does not. I bring this up
because the equivalent "Sequel" statement allows a standardized syntax and
performs exactly the way you'd wish: updates TableA only when the keys
match. No worries about SQL0811 and no unwanted nulls. See below example.

UPDATE SET((a.update_field b.update_field))
SQL('FROM TableA a, TableB b INNER JOIN
a.key_field=b.key_field')

Question: Is it possible that iSeries SQL allows non-standard SQL
extensions or have the ASC programmers cleverly parsed and reformatted the
statement to allow their own syntax? I'm making a note for next week to ask
their tech-support about this, but thought I'd see whether anyone on this
list has already investigated this.

JK


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.