DBCENTURY

Hi folks, At the informix website my version of my database OWS 7.20.UC2 is Y2K compliant. However when I put in my profile DBCENTURY=C export DBCENTURY afterwards I'm doing oninit But I ain't seeing a difference. When I put 120100, the date 12/01/1900 is displayed. Following the notes this is not normal. What do I need to change. Anybody an idea?? Thanks anyway, Danny

"nieuwsgroepen" <Fidelity@fidelity-soft.be> wrote: >Hi folks, > >At the informix website my version of my database OWS 7.20.UC2 is Y2K >compliant. However when I put in my profile > DBCENTURY=C > export DBCENTURY > > afterwards I'm doing oninit > >But I ain't seeing a difference. When I put 120100, the date 12/01/1900 is >displayed. Following the notes this is not normal. What do I need to >change. >Anybody an idea?? > >Thanks anyway, > >Danny > > I didn't know 7.20 supported DBCENTURY! We are running 7.22 UC2 on AIX and that doesn't to my recollection do so. We are running C4GL 6.04.UC2. What these do is that dbacces (and SQL sent to it from 4GL) always uses current (ie 2000), and 4GL always uses 19xx. To my knowledge you need 7.23 to be able to use DBCENTURY. Compliance is one thing - understanding what people mean when they type in to little information is another ;) Even if your engine supports it, your programming language is usualle a couple of versions behind (4GL is!), and might not support things that the engine does, so select unique year("010199") from systables might work as intended, but let r_data.mydate = "010199" ...inserting data into table... might not, as this dateconversion isnt really done by the engine. //F.E.Theodorsen Finn E. Theodorsen///theodor@inet.uni2.dk///AtCbM///Legend#219605 TEN: Durax. Homepage: http://www.theodor.suite.dk/index.htm All advertisments sent to the above address will be treated as requests for computer support, and charged accordingly. Sending these kind of messages equals an acceptance of these terms. The minimum fee is $500.

"Finn E. Theodorsen" wrote: > "nieuwsgroepen" <Fidelity@fidelity-soft.be> wrote: > >At the informix website my version of my database OWS 7.20.UC2 is Y2K > >compliant. However when I put in my profile > > DBCENTURY=C > > export DBCENTURY > > > > afterwards I'm doing oninit > > > >But I ain't seeing a difference. When I put 120100, the date 12/01/1900 is > >displayed. Following the notes this is not normal. What do I need to > change. > >Anybody an idea?? > > I didn't know 7.20 supported DBCENTURY! It does. All the 7.2x products support DBCENTURY. Not all of them are completely Y2K compliant -- that's why you have to upgrade beyond 7.20.UC1 -- but they all aupport DBCENTURY. > We are running 7.22 UC2 on AIX and that doesn't to my recollection do > so. We are running C4GL 6.04.UC2. Of course, 6.04 I4GL was not DBCENTURY aware. Funnily enough, 7.20 I4GL was the version that was DBCENTURY aware. > What these do is that dbacces (and SQL sent to it from 4GL) always By default, I4GL does not send any SQL to DB-Access. > uses current (ie 2000), and 4GL always uses 19xx. > > To my knowledge you need 7.23 to be able to use DBCENTURY. Nope, but you need 7.23 (or, better, 7.24) to be reasonably Y2K-safe. > Compliance is one thing - understanding what people mean when > they type in to little information is another ;) > > Even if your engine supports it, your programming language > is usualle a couple of versions behind (4GL is!), and might > not support things that the engine does, so > > select unique year("010199") from systables> > might work as intended, but > > let r_data.mydate = "010199" > ...inserting data into table... > > might not, as this dateconversion isnt really done by the engine. This is the key point; is the conversion done in the application or the server. For safety, you need both server and application to be fully aware of DBCENTURY. If one is and one is not, you can arrange for errors to occur in date handling that would not occur if both were aware of DBCENTURY (or if neither was aware of it). -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.95 -- see http://www.perl.com/CPAN #include <disclaimer.h>