Re: Interesting question and debate on ddl tables with date fieldsthatwill not always have a value

I kinda sorta agree...

It's be nice if RPG supported stand-a-lone null capable fields.

However, in the context of modern application design, where the DB I/O
is wrapped by a service program, there's a couple of tricks I've used:

Varying Alpha fields, a length of 0 is equivalent to NULL.

Use DS defined types:

d t_DateNULL ds based(TEMPLATE)
d isNull n
d value d

d terminationDate ds likeds(t_DateNULL)

/free
if not terminationDate.isNull;
//do something
endif;
/end-free

HTH,
Charles


On Tue, Oct 14, 2008 at 3:00 PM, DeLong, Eric <EDeLong@xxxxxxxxxxxxxxx> wrote:

So, are you saying that you use null support for all your business
applications? From the perspective of your users, would they ever be
able to tell the difference between an application using null support,
and an application using legacy techniques?

Seriously, my gripe is not the concept of null value, or even how SQL
processes in the presence of null values, but is about how hard (messy)
it is in a HLL like RPG. The reality is, if you MUST support null
capable fields in RPG, you must ALWAYS check the null indicator before
you EVER access the field in question. Did you know that even a null
field will still return a valid value during a fetch? It might be the
default initial value for that data type, or it might contain some other
value (assuming the field was set to null AFTER it had a value stored).


If IBM made null support more transparent, I would probably recommend it
usage. As it is, I don't think most developers would be disciplined
enough to always use it properly.

JMO,
Eric DeLong

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Tuesday, October 14, 2008 1:02 PM
To: Midrange Systems Technical Discussion
Subject: RE: Interesting question and debate on ddl tables with date
fieldsthatwill not always have a value

Use nulls, that's what they're for!

Not to make this an state-of-the-nation discussion, but it's the very
fact that many people aren't willing to use the "current" stuff, that
makes an i look old. Imagine this question from an outsiders point of
view... the rest of the world uses null, to a SQL Server programmer this
wouldn't even be a question. Looking at an i, we'd see that we "can't"
use nulls, so i must be old! Granted, it's not that the i can't handle
them technically, but that our programmers can't handle them. Well,
sooner or later the programmers have to upgrade their skills, or guess
what, the machine IS old.

-Walden

--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Doug Palme
Sent: Tuesday, October 14, 2008 12:06 PM
To: Midrange Systems Technical Discussion
Subject: Interesting question and debate on ddl tables with date fields
thatwill not always have a value

I hope that subject description makes it clear. We are having an
internal
debate and discussion as we make the move towards sql tables and ddl
files; specifically using date data types.

An example, an employee file has two dates, HireDate and TermDate,
self
explanatory.....one is when the person is hired and the other is when
they
leave.

Obviously while they are an employee, they do not have a term date,
so how
do we handle that?

suggestions? comments? thoughts?

This transmission may contain information that is privileged,
confidential
and/or exempt from disclosure under applicable law. If you are not
the
intended recipient, you are hereby notified that any disclosure,
copying,
distribution, or use of the information contained herein (including
any
reliance thereon) is STRICTLY PROHIBITED. If you received this
transmission in error, please immediately contact the sender and
destroy
the material in its entirety, whether in electronic or hard copy
format.
Thank you.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.