I don't think it is too difficult and the last hour has proved to be
extremely fruitful for me......what I fear is we have some people that
absolutely will drag their feet on this, because they believe in the
philosophy that "if it ain't broke don't fix it".
They are used to doing things a certain way and refuse to change.
They seem to think that there will be a bogus date in the field, when in
actuality if you look at it with STRSQL it shows NO DATE at all..... it
shows a short dash.....which makes it pretty damn obvious to me that we
have no date in the field.
I feel like I am beating my head against the wall on some of this....the
one advantage is, the department head has mandated that we WILL move
forward one way or another.......and I think for some its they don't want
to learn something new.
oh well, sorry for my rant....I just spent 15 minutes arguing with someone
over this very issue and they ended the conversation with "I think it is
stupid"
From: rob@xxxxxxxxx
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 10/14/2008 03:24 PM
Subject: RE: Interesting question and debate on ddl tables with
date fieldsthatwill not always have a value
----------------------------------------------------------------------
One - I don't see this as too tricky:
if %nullind(termDate);
dsply 'employee is active';
else;
dsply 'employee was terminated ' + %char(termDate);
endIf;
or any more lines of code than
if termDate = MichelangelosBirthday;
dsply 'employee is active';
else;
dsply 'employee was terminated ' + %char(termDate);
endIf;
You do have some leg to stand on that if an incompetent programmer were to
check termDate without checking it's null indicator they can get into
trouble. For example if I do
termDate = date(); // set to current date
%nullind(termDate) = *on; // set termDate off as employee is active
dsply termDate; // even though null, it will still display today's date
But, who's to say that same programmer wouldn't figure that a date of
0001-01-01 or Michelangelo's Birthday or whatever wasn't a valid date?
Were you hoping that IBM had written the compiler so that if you tried
dsply termDate;
and if termDate was null then you'd get a messy MCH type message as if you
tried to dsply a variable that wasn't passed into the program and you
failed to check %addr on that?
I take it you also have an issue with
select termDate
into :termDate :termDateInd
from ....
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
"DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/14/2008 03:04 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc
Subject
RE: Interesting question and debate on ddl tables with date fieldsthatwill
not always have a value
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.
--
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 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.
midrange.com
