2/29/2000 Problem?
Posted in 2000
Topics: Installation, Setup & Upgrades, Connectivity: ESQL/C, 4GL & Embedded SQL, Migration, Import/Export & Data Conversion, Platform-Specific Issues
I'm working with someone who is upgrading to: 4GL RDS 7.20.UE1 SQL 7.20.UE1 SE 7.24.UC8 on Sun Ultra 5 running Solaris 2.7 They indicate: after migration and upgrade of existing database, there is a 2-29-2000 issue that needs to be address. The Informix database will not accept a record load with a 2-29 Due Date or Send Date entry. Is there a Y2K problem with SE involving 2-29-2000? Vic
Victor Glass wrote: > I'm working with someone who is upgrading to: > 4GL RDS 7.20.UE1 > SQL 7.20.UE1 > SE 7.24.UC8 > on Sun Ultra 5 running Solaris 2.7 > > They indicate: > after migration and upgrade of existing database, there is a 2-29-2000 > issue > that needs to be address. The Informix database will not accept a > record > load with a 2-29 Due Date or Send Date entry. > > Is there a Y2K problem with SE involving 2-29-2000? > > Vic In some earlier versions the year 2,000 is considered not to be a leap year. Some one suggested a few days ago he was going to switch his system off on the 29th to avoide any problems. -- Compliments of QueriX -------------------------------------------------------------------------------------------------- QueriX 4GL Compilers are Informix 4GL Compatible, and Connection to other RDBMS such as Oracle. Hydra 4GL Compiler (Compatible with I4GL) Compile once, run everywhere Phoenix Windows GUI. (Front End to 4GL) Chimera Java GUI The only GUI you will ever need... (Front End to 4GL) Arachne Web Technology (Front End to 4GL on the Web) For more details visit: http://www.querix.com/ ---------------------------------------------------------------------------------------------------
Some 7.24 versions had a bug dealing with 2/29/2000. The Informix WEB Site has a Y2K issues page that explicitely states which versions have the problem and which it is safe to upgrade to. Versions 7.3x do not have this bug, and I believe 7.24UC10+ is OK, but check it out. Art S. Kagel Victor Glass wrote: > I'm working with someone who is upgrading to: > 4GL RDS 7.20.UE1 > SQL 7.20.UE1 > SE 7.24.UC8 > on Sun Ultra 5 running Solaris 2.7 > > They indicate: > after migration and upgrade of existing database, there is a 2-29-2000 > issue > that needs to be address. The Informix database will not accept a > record > load with a 2-29 Due Date or Send Date entry. > > Is there a Y2K problem with SE involving 2-29-2000? > > Vic
Some 7.24 versions had a bug dealing with 2/29/2000. The Informix WEB Site has a Y2K issues page that explicitely states which versions have the problem and which it is safe to upgrade to. Versions 7.3x do not have this bug, and I believe 7.24UC10+ is OK, but check it out. Art S. Kagel Victor Glass wrote: > I'm working with someone who is upgrading to: > 4GL RDS 7.20.UE1 > SQL 7.20.UE1 > SE 7.24.UC8 > on Sun Ultra 5 running Solaris 2.7 > > They indicate: > after migration and upgrade of existing database, there is a 2-29-2000 > issue > that needs to be address. The Informix database will not accept a > record > load with a 2-29 Due Date or Send Date entry. > > Is there a Y2K problem with SE involving 2-29-2000? > > Vic
Victor Glass wrote: > I'm working with someone who is upgrading to: > 4GL RDS 7.20.UE1 > SQL 7.20.UE1 > SE 7.24.UC8 > on Sun Ultra 5 running Solaris 2.7 > > They indicate: after migration and upgrade of existing database, there > is a 2-29-2000 > issue that needs to be address. The Informix database will not accept a > record > load with a 2-29 Due Date or Send Date entry. > > Is there a Y2K problem with SE involving 2-29-2000? A number of people have responded that some versions of the products have problems with 2000-02-29, and they are accurate but incomplete. There was an infamous bug number in the 60000..70000 range (so infamous I've forgotten what it was), that would cause a two-digit year value to fail when converting 29/2/00 or 2/29/00 or 00-2-29; the failure was "invalid year in date", not the expected invalid date error. The best workaround is to ensure that all dates are always printed, unloaded, displayed, etc with 4-digit strings for the year. The version numbers you quote are rather high still to be running into this bug. Check out the Y2K page at the Informix web site; there may be specific information there for your software. If it isn't this problem, then maybe you can demonstrate the loaded data with a couple of simple date values failing to load into a single column table... -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.95 -- see http://www.perl.com/CPAN #include <disclaimer.h>