Re: Current century not being picked up

You have to set DBCENTURY to "C" which means closest. You can do it for each user session, or if using windozs clients with setnet32 utility. Also you can set it before the IDS server starts e.g. in an init script. AFAIK the version of the frontends is unimportant. The version of the IDS is critical. Unfortunately I don´t know the lowest version number of IDS which supports DBCENTURY HTH Reinhard <deeky@my-deja.com> schrieb in im Newsbeitrag: 84t0nd$4sg$1@nnrp1.deja.com... > Hi all, > > We are running IDS 7.24-UC5.8 of IDS and 6.04 UC2 of 4GL and SQL. > We are also running AIX 4.3.3.1 which has passed the IBM "fixcheck" Y@K > test fine. > > Our problem is when we enter a 2 digit date "00" it is converted to > "1900". I know using 4 digit dates is the answer, but unfortunatly the > third party application allows for the entry of 2-digit dates. > > From what I have readon DBCENTURY I will need to upgrade SQL and 4GL to > 7.2X in order to use DBCENTURY functionality. However, I was lead to > believe that the current versions of these products are supposed to use > the current cenrtury for year expansion as a default. This does not > explain why if my system date is correct and my O/S is Y2K, how come > "00" converts to "1900"? > > Any thoughts on my situation? > > TIA > > Derrick > > > Sent via Deja.com http://www.deja.com/ > Before you buy.

Reinhard Habichtsberg wrote: > You have to set DBCENTURY to "C" which means closest. > You can do it for each user session, or if using windozs clients with setnet32 utility. > > Also you can set it before the IDS server starts e.g. in an init script. > > AFAIK the version of the frontends is unimportant. The version of the > IDS is critical. Unfortunately I don´t know the lowest version number of IDS > which supports DBCENTURY > > HTH > Reinhard > > <deeky@my-deja.com> schrieb in im Newsbeitrag: 84t0nd$4sg$1@nnrp1.deja.com... > > Hi all, > > > > We are running IDS 7.24-UC5.8 of IDS and 6.04 UC2 of 4GL and SQL. > > We are also running AIX 4.3.3.1 which has passed the IBM "fixcheck" Y@K > > test fine. > > > > Our problem is when we enter a 2 digit date "00" it is converted to > > "1900". I know using 4 digit dates is the answer, but unfortunatly the > > third party application allows for the entry of 2-digit dates. > > > > From what I have readon DBCENTURY I will need to upgrade SQL and 4GL to > > 7.2X in order to use DBCENTURY functionality. However, I was lead to > > believe that the current versions of these products are supposed to use > > the current cenrtury for year expansion as a default. This does not > > explain why if my system date is correct and my O/S is Y2K, how come > > "00" converts to "1900"? As I recall (not very far), only the same versions which support DBCENTURY will use the "current" century. Others used "the century which was current when the product was written", or 1900. And yes, the front-end version definitely does matter. As long as the front-end is storing the date into a DATE datatype, it is doing the conversion, and the rules for the century will be applied depending on the version (and, if applicable, DBCENTURY setting) of the front-end. Only if the front-end sends a character datatype will the back-end do the conversion, and the back-end's version and DBCENTURY setting take effect. I tried to cover this in my TechNotes article, which was published in 1998, but by the time someone had finished hacking my article, this point (which was, of course, the MAIN point) had been completely lost in noise. sheesh. (not that I'm bitter or anything :-) June -- june_t@hotmail.com Back from the dead, resuscitated by Godiva chocolates... Please do not send Informix questions to this account.