RE: RPG IV not up to the task of reading and writing to DB files....

Hello Joe,

Yeah, I've read the arguments for and against NULLs.

I've kind of taken a middle of the road approach.  Basically, I'm using
NULL capable fields for foreign key columns that may or may not contain
a value.

I've considered pointers, but while I'm plenty comfortable with them,
I'm not sure you can say that about most RPG programmers.  I know the
other developers here would find them disconcerting.  So I try to stay
away from pointers if at all possible.

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
> Sent: Thursday, May 18, 2006 7:41 PM
> To: 'RPG programming on the AS400 / iSeries'
> Subject: RE: RPG IV not up to the task of reading and writing 
> to DB files....
> 
> Hi Charles!
> 
> I guess this whole thing depends on what your business 
> purpose is.  Are you
> trying to create an environment where you can create fields 
> with any value,
> but have a special flag that says "no value set"?  That of 
> course means
> passing an extra byte around for every field on every call 
> (and maybe even
> an extra entry on the stack).  If you think this is a 
> necessity, then just
> pass the null indicator as an extra parameter!  I understand 
> you want to
> make the compiler do it for you (and as Barbara points out, 
> they're almost
> there) but personally I think there are other ways around 
> this particular
> problem.
> 
> One is to pass pointers.  Set the pointer null if the null 
> indicator is set.
> Another option is to create a non-valid value and, as Scott suggests,
> convert between null and the invalid value in your database 
> routine (as
> Scott says, with an architecture this layered, you should 
> definitely have
> complete I/O encapsulation).
> 
> I've read some very good treatises that argue AGAINST nulls.  
> They instead
> insist that an actual flag be included in the database that identifies
> whether the field has a value or not (with a corresponding 
> name or perhaps
> even a value that indicates why the data is not present).  There are
> compelling arguments in either direction, with the primary 
> argument FOR the
> implicit NULL value being the fact that most RDBMSs include 
> the ability to
> COALESCE.  This is really a relatively moot point; given the fact that
> people don't always agree on what happens when you combine 
> null and non-null
> values, especially in mathematical equations, the best I've 
> been able to
> make of the current "state of expert opinion" is that nulls 
> should be used
> sparingly, for very special cases where business logic really 
> depends on a
> state where the data is unknown.
> 
> And in that case, using either a pointer or including a 
> separate flag may
> well be a good idea.  I know I'd hate to start coding all my 
> code with the
> idea that EVERY field might be null-capable...
> 
> Joe
> 
> P.S. Here's my address checker:
> 
> p Addr            b                        
> d                 pi              *        
> d   pField                        *   value
> d   nField                        n   value
>  /free                                     
>   if nField;                               
>     pField = *null;                        
>   endif;                                   
>   return pField;                           
>  /end-free                                 
> p                 e                        
> 
> Just check this way:
> 
> myFieldAddr = Addr( %addr(myField): %nullind(myField));
> 
> 
>