Re: Informix 4GL and year 2000 problems/ramblings

On 8 Dec 96 at 1:53, Billy Wheeler wrote: > > 1) First of all, I've heard various things about DBCENTURY. I've heard > > it only applies to the engine and not the tools. > > Now I'm confused. How is DBCENTURY going to do anything if it only > gets used by the engine? Here, for example, where the engine gets a hold of the string and has to convert it: INSERT INTO sometable VALUES ("XXX", "12/8/96") SELECT * FROM sometable WHERE datefield BETWEEN "12/1/96" AND "12/31/96" > > I've heard DBCENTURY has no effect to any of the 4GL versions. > > Is this correct? > > It might be true, although I'm sure they'll fix that soon enough... Below is some info from Jonathan Leffler (at Informix) and others that I found in the IIUG newsgroup archives. Apparently, tools based on ESQL/C 7.20 are supposed to behave correctly. According to Jonathan, "No release of I4GL using the 7.20 ESQL/C (or later) is planned". My engine is 7.20, my 4GL is 6.04. And, I4GL = c4gl? Apparently, I'm passed over as a 4GL user. > If it doesn't already (I haven't checked, to be honest), it will do > soon. I couldn't believe even Informix would be that dumb. Or maybe > they're hoping everyone will migrate to NewEra before 2000... :-) I guess everybody else in the world has graphical platforms (or wants to use the ascii terminal NewEra interface). Sorry, I don't care how trendy GUI interfaces are. A person unloading a truck isn't going to be looking at pie charts. A $400 ascii terminal is more cost-effective than a $2000 or more graphical platform. ############################################################################# > From: johnl@informix.com (Jonathan Leffler) > Date: 15 Mar 1996 21:23:05 -0500 > > At the risk of boring you by resuscitating an old subject... > > >Date: Sun, 10 Mar 1996 10:03:30 -0500 (EST) > >From: Nick Nobbe <nnob@loc.gov> > > > > At our recent annual user group forum, I learned that Informix has > > just this kind of feature, namely DBCENTURY, in version 7.2. > > You can set this variable to closest year, i.e. year in the closest > > century (where 1/1/02 = 1/1/2002), closest past year, > > closest future year, and closest future year, with your date > > (DBDATE) environment variable set to 2-digit years. > > Nick is correct. If you are using a product based on any version of ESQL/C > prior to version 7.20, the current behaviour, which is to add 1900 to > 2-digit years when a string is converted to a date, will continue to occur. > This means, if you have not already cottoned onto it, that in the year > 2000, if your forms do not allow the user to enter and see 4 digits for the > year, you will inevitably get incorrect data in the database. You can help > prevent that by adding CHECK constraints to your data columns, such as: > > CHECK (YEAR(datecol) >= 1950) > > Only if your code is based on a product using the (as yet unreleased) 7.20 > ESQL/C, or some later version, will you get the more flexible behaviour > given by the DBCENTURY environment variable, which is documented below. At > the moment, there are no plans to back-port this to any of the version 4, 5 > or 6 products. > > Yours, > Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> ############################################################################# > From: johnl@informix.com (Jonathan Leffler) > Date: 25 Mar 1996 12:53:23 -0500 > > The 7.20 ESQL/C library uses the DBCENTURY environment variable > to allow users to control way 2-digit years are mapped to 4-digit > years. No release of I4GL using the 7.20 ESQL/C (or later) is planned. > You will have to enter and display 4-digit years. ############################################################################# > From: prushie@aol.com (PRushie) > Date: 7 May 1996 20:34:30 -0400 > > According to Informix with Version 7.2 and beyond (due out in July), there > will be an enviroment variable DBCENTURY which will allow you to set how > Informix reacts when you enter only 2 digits in a year. Specifically you > can set it to use the current century, previous century, next century, or > closest century. Closest seems to be the best option for most cases, that > is if you enter 99 it will determine if 1999 or 2099 is closer to the > current year and use which ever is closer. ############################################################################# > > One application may have a variety of dates, like employee birthdate > > (always in the past). The same screen may have retirement date or > > review date (future). Other fields may need the "closest" logic. > > Ha - now this is tricky. My feeling (as another developer who has > many, er, users) is that there isn't really much you can do about > this. Using the logic below, if I was born in '45 and retired in '99, > you'd have me retiring in 2099. And I'm buggered if I'm waiting that > long! :-) > > > BEFORE FIELD birth_date > > CALL set_dbcentury("P") # past (closest previous year) > > > > BEFORE FIELD retirement_date > > CALL set_dbcentury("F") # future (closest future year) I don't follow how a '99 retirement date would resolve to 2099. If you'd enter that today (in '96), the closest "future" date ending in '99 is 1999. I don't think the "F" applies to future "century", just that the 100 year range of possible dates is future, even if that's still in the 1900's. For example, "F" as of today would be 1997 - 2096 (or maybe it includes this year 1996 - 2095). __________________________________________________________________________ Joel Schumacher JCPenney Co. - UNIX Network Systems jschumac@uns-dv1.jcpenney.com 12700 Park Central Pl (972) 591-7543 Dallas TX 75251