informix tools Y2K issues
Informix has stated that in order to be Y2K complient, we must either be running version 4 or version 7 of their development tools. We are currently using version 6.04.UC1 of their rapid development tools, and so far have not detected any incompatibilities through our own testing. We are avoiding upgrading to version 7 as the migration path is too complex. Could someone let me know what known Y2K problems are associated with version 6? I have asked Informix but have not been able to get a clear answer. Thanks in advance! -tom
TomMartins wrote: > Informix has stated that in order to be Y2K complient, we must > either be running version 4 or version 7 of their development tools. 4.2 or 7.2 or later. > We are currently using version 6.04.UC1 of their rapid development > tools, and so far have not detected any incompatibilities through > our own testing. We are avoiding upgrading to version 7 as the > migration path is too complex. > > Could someone let me know what known Y2K problems are associated with > version 6? I have asked Informix but have not been able to get a > clear answer. You will have by the time you've finished reading this... 1. If you type 2 digits for the year component of the date after the turn of the century, I4GL-RDS 6.x will continue to add 1900 to the date, as documented. This is probably not what you want. 2. If you don't display all 4 digits for the year, the 1900 substitution will still occur, but the user won't know that is has happened. 3. You won't have the option of using the DBCENTURY environment variable. 4. You won't get all the goodies that will arrive with the 7.30 version of I4GL, including the CENTURY field attributes. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>
Primary Y2K issue is related to the use of 2-digit year input in 4gl code. When inserting or updating a date or datetime field, a "2-digit" year will always default to "19xx" -- regardless of the system clock ( 1999, or 2000+). If you have 2-digit year input, it is often possible to convert the year prior to actual storing in the database (i.e. convert dates in a loadfile to 4-digit years before inserting). Interception of the date can also be performed when using keyboard user input (i.e. a 4gl form) However, if the 4gl forms use input fields defined as 2-digit years, some dates will cause invalid errors. For example, the date "02/29/2000" is valid, but if it is input as "02/29/00", it will be expanded to "02/29/1900" which is not a valid date (1900 was not a leap year), therefore the 4gl form will generate a validation error before your conversion function is called. THe only way around this is to make the field a 4-digit year. Version 7.20 (a.k.a. 6.10) and 4.20? resolve this issue by expanding the 2-digit year to the current system clock's year. It also introduces an environment variable DBCENTURY that provides for "current", "closest", etc. logic -- I recommend not to use it unless it is the last resort. Being an env. var., it is too easily modified, or unset, which would result in data input errors that might go undetected for an extended time. Documentation exists on the Informix web site (in the Y2K section) about this feature and the risks of using it. Walker TomMartins <tommartins@aol.com> wrote in message news:19990622172005.07115.00002617@ng-ca1.aol.com... > > Informix has stated that in order to be Y2K complient, we must either be > running version 4 or version 7 of their development tools. > > We are currently using version 6.04.UC1 of their rapid development tools, > and so far have not detected any incompatibilities through our own testing. We > are > avoiding upgrading to version 7 as the migration path is too complex. > > Could someone let me know what known Y2K problems are associated with > version 6? I have asked Informix but have not been able to get a clear answer. > > Thanks in advance! > -tom