Re: SQL Statements embedded in RPG

["David Morris" <dmorris@xxxxxxxxxxxxx>]

Tom,

I wasn't clear.  The SQL pre-compiler does not support everything that RPG 
does.   By 
declaring a source member as SQLRPGLE you cannot use things like embedded 
/copy, null 
support, new BIFS, etc.  This is really a pain.  If you use CODE/400 the 
development process 
is also severely hampered.  By separating the SQL portion of your application 
and putting it 
in a separate module, only the SQL module is restricted.  The non-SQL modules 
that use the 
SQL module can still take advantage of all of the neat new features of RPGIV.

As far as modularity enhancing your applications, that is the biggest benefit 
to using the ILE 
environment.  The simplification comes about because you can define a better 
interface to 
your application than SQL provides.  For example, rather than declaring 
cursors, pointers, 
SQLDAs, and interpreting SQLCODs, you simply call a routine that opens a cursor 
and 
start fetching records.  The implementation of SQL is hidden.

David Morris  

>>> Tom_Tufankjian@hbltd.com 02/17/00 10:04AM >>>



David Morris wrote:

>One advantage to embedding the SQL in a separate module is that the SQL
pre-compiler
>does not support all of RPG's capabilities.

How is this an advantage by not supporting all of RPG's capabilities?


>The other advantage is that it simplifies the
>use of SQL.

How is the use of SQL simplified by embedding in a separate module?

tks,
tom t


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---