RE: Free format sql, was: Nice trick for easy viewing free-form RPG and embedded SQL

Rob,

Good arguments, and I agree totally.

I, too, wonder why a lot are tending to write set- and get-methods with file 
I/O. Either they read the same record many times to get each and every single 
value, or they use a global variable somewhere, which is an absolute "No! No!!" 
in their design principles, hence the use of those methods.

But my idea to externalizing the SQL calls in embedded SQL is when using 
dynamic SQL. I am aware that not all situations fit. But when using embedded 
SQL to generate reports or output to the IFS I think one programme, using 
dynamic SQL in a service programme I would be more productive than when writing 
a programme for each report/output. So, I would have to write only one SQLRPGLE 
programme and do not have to be reminded of the limitations of the SQL 
precompiler.

The structure for each programme is the same: build the SQL statement, prepare, 
open, fetch, close.

When using multiple SQL statements (with updates or inserts) it would be more 
difficult to externalize it this way.

Just my thoughts.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 19-7-05 at 11:07 rob@xxxxxxxxx wrote:

>Basically I am not a big fan of externalizing I/O because it's been my 
>impression that a bulk of the people who are enthused 
>about it are the ones who write the external I/O routines.  Not the consumers 
>of the routines.
>
>I'd rather write a program that does something like
>FMyFile....
> /free
>  read(e) MyFile;
>  Dow %status(MyFile)=ReadOk;
>    // process the data
>    read(e) MyFile;
>  EndDo;
>  Select;
>  When %status(MyFile)=EOF;
>    // Ok, don't worry about this one
>  Other;
>    // Oh darn!!!
>    ...
>  EndSl;
>
>Than a program that does something like
>/free
>Select;
>  When OpenInventoryData()=Cool;
>    Select;
>    When GetInventoryData(Key1: Key2...)=Cool;
>      MyField1=GetBalance();
>      MyField2=GetWarehouse();
>...
>Some externalizing gurus might say you wouldn't have a GetInventoryData. 
>Instead the keys would be on the GetBalance, etc.  Then >what, does it read a 
>record for each field requested?  I'm not expecting an answer.  It's just a 
>sample of how externalizing may raise >more questions than it solves.
>
>Oh, there's the popular myth that if I change a file structure then I do not 
>need to worry about it if I've externalized.  My counter is >that a popular 
>package changed the size of their key field and all the rest of their fields.  
>So if I have a program
>D MyItem         s            15a
>D ItemDesc       s            30a
>I still have issues.  Now, if I've LIKEd these fields off of an external data 
>structure I'm better off.  I still have to compile though.  (And 
>maybe redesign any 5250 screens to change the layout, etc).  Then again, isn't 
>using an external method supposed to hide from >your developers what the name 
>of the actual physical file is?  If so, how would they know file(s) to use in 
>the data structure(s)?