|
For a "from-scratch" application, I agree this is how it should be done. One problem is most RPG programmers have not encountered nullable fields before. Can/does RPG/III support null capable fields? I know RPG/IV has %nulind to check against. Convert all programs to RPG/IV, recompile with ALWNULL(*USRCTL), and bracket date operations with %nulind. I agree technically that one shouldn't use a "real" date to represent no date, but with as much legacy code with 6,0 or 8,0 numeric with 0 for no date, I think the "0001-01-01" is reasonable. Loyd -----Original Message----- From: R. Bruce Hoffman, Jr. [mailto:rbruceh@attglobal.net] Sent: Thursday, August 22, 2002 9:00 AM To: midrange-l@midrange.com Subject: Re: Allow *ZERO in a date (and timestamp) field? IBM? ----- Original Message ----- From: "William A.(Tony) Corbett" <corbett@ASRESOURCES.COM> To: "MIDRANGE-L@midrange. com" <MIDRANGE-L@midrange.com> Sent: Thursday, August 22, 2002 9:05 AM Subject: Allow *ZERO in a date (and timestamp) field? IBM? > If the "date field restrictions" could be eased up to allow only valid dates > (as it is now) OR zero in a date field, this would help us a lot. > > I am currently having to using a packed field to store dates on the > db, primarily due to this restriction. Oftentimes, I need to allow a > zero in a > date field, and current restrictions will not allow this. while I understand the wish, it is not likely to ever be changed. And I think "help us" is a key mentality here... it sure won't help the developers that follow us. One should never use a value to represent a "no value" condition and that's what you are doing. A null value is what is used to represent that condition. Since nulls are viable in date fields, you would/should convert your dates and null those dates that are zero. And, yes, application code would all have to change then too. =========================================================== R. Bruce Hoffman, Jr.
As an Amazon Associate we earn from qualifying purchases.
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.