× 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.



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));



> From: Wilt, Charles
> Subject: RPG IV not up to the task of reading and writing to DB files....
> 
> <vent>
> 
> I've come to that conclusion after banging my head against the wall of
> RPG's (lack of) NULL support.



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.