What happen Informix? - Y2K Issues in Informix

What happen Informix? - Y2K Issues in Informix

Post by Varadharajan M Kop » Sun, 31 Dec 1899 09:00:00




> On Wed, 27 May 1998 08:36:17 -0600, "Gustavo A. Murillo Fuentes"

> >       One company of software in Costa Rica, associated with Oracle, say without
> >problem: "We are created one tool for migration since the obsolete Informix
> >tecnology to Oracle tecnology" and they suggested between lines, what
> >Informix 4GL have problems with the Y2K!!!.  What happen Informix? :-(

> 1. There are no Y2K problems with Informix 4GL appart from those you
> created yourself by using only 2 digts for years in input fields. Even
> these are solved by Informix in ver. 4.20 and 7.20 of 4GL via the
> DBCENTURY environement variable. I would assume this company have done
> something similar.

Right from the day I started writing any date, I have always used 2
digit years. This was the CONVENTION. Naturally, most of the programmers
have used 2 digit years in their code and system design. So we may not
have used 4 digit year in screen or reports. These may be problems
created by us but let us not kid ourselves.

That DBCENTURY will take care of everything may not be entirely true.
Most of the applications, yes. But applications which deals with date
which spans more than +-50 years could pose problems. This may  or may
not be likely in many applications and you are the best judge regarding
your application.

Informix does not have any problem in storing dates that belong to
different centuries. But the problem is what happens when we cross the
year 2000 with 2 digit year all over in my application.
Informix gives you DBCENTURY environment variable which can have values
F - Future, P - Past, C - Closest, R - Current century which is the
default.

Let us say if you are having screens which accept 2 digit dates for some
thing like a date of birth ( past date ),  date of next increment (
future date ) (when compared to the current date). Suppose the values
are as follows :
Date of Birth = 1/1/49   ( 1949 )
Date of next increment = 1/1/1 ( 2001 )
Current Date =  3/ 1/ 00 ( 2000 )

DBCENTURY = P ( Consider past and present century, Chose prior date )
 Date of Birth = 1/1/1949 and 1/1/2049  Prior date is 1/1/1949
* Date of next increment = 1/1/1901 and 1/1/2001 Prior date is 1/1/1901
  stored as 1901
 DBCENTURY = P will not work for date of next increment

DBCENTURY = F ( Consider present and future century. Chose future date )
* Date of Birth = 1/1/1949 and 1/1/2049  Future date is 1/1/2049 stored
as 2049
 Date of next increment = 1/1/1901 and 1/1/2001 Future date is 1/1/2001
 DBCENTURY = F will not work for date of birth

DBCENTURY = C ( Consider past, present and future century. Chose closest
date )
* Date of Birth = 1/1/1949,  1/1/2049, 1/1/2149  Closest date 1/1/2049
 Date of next increment = 1/1/1901, 1/1/2001, 1/1/2101
   Closest date is 1/1/2001
 DBCENTURY = C will not work for date of birth

DBCENTURY = R ( Consider present century. Chose current century date )
* Date of Birth =  1/1/2049  
 Date of next increment =  1/1/2001
 DBCENTURY = R will not work for date of birth

Note that we can not be flipping environment variable between different
data entry screens. Now the problem is clearly applications which deal
with dates > + or - 50 years from current date using 2 digit years. In
this case year 49 falls outside the 50 year  boundary. Hence same
DBCENTURY setting may not work for all date columns in your application.

The simplest solution is USE 4 DIGIT YEARS, so that Informix knows which
year without having to interpret using DBCENTURY. Now this means, we
have to look at screen layout to see if we can accomodate 4 digit year
during entry and CHANGE it. Reporting may not be a problem, since we
have the common sense to read a 2 digit year on print and interpret the
correct century. Data transfer between external systems may also pose a
problem and require CHANGE.

If we are not changing to 4 digit years, with any of the above DBCENTURY
setting, we can take care of about half the dates as 2 digit dates, but
we may have to code some logic to interpret the correct century for the
others. For example, I could leave DBCENTURY as Current/Closest and put
some code in after field clause of Date of Birth. This means CHANGE in
application.

For date values stored in character or smallint fields it is totally a
different story. It is like COBOL. I have seen atleast one such Informix
application.

THIS PROBLEM MUST EXIST IN ORACLE TOO. There may be tools. But we also
have tools for Informix or atleast develop if we do not have. We are
developing some tools for analysis and conversion for fixing Y2K
problems.

May be Informix can provide a better fix. A SET CENTURY statement  may
work which I can plug in for some problem date fields. But this may lead
to other problems after a certain date ( standard windowing technique).

We should  think about this Y2K problem to see if we can arrive at a
better solution and propose to Informix. May be Informix folks have
already given it too much thought and had arrived at this DBCENTURY as
the best fix. We represent the Informix world and we really need to
provide good suggestions.

I would sincerely recommend changing applications to 4 digit years if
there are problem date fields. May be, we need to have a NEW CONVENTION,
read and write 4 digit years.

If my above interpretation of DBCENTURY is wrong please correct me. I
have tested the above values by resetting system clock and doing insert
with different DBCENTURY settings using dbaccess and then did a select
with DBDATE set as DMY4. And that is how the values got stored. I had
used 7.22 UC1. Actually I had done this long time back when the feature
was announced. I will have to test using the latest version of 4GL, IDS
and ESQL/C to see if it is any different. Has any one tested using 4GL
and ESQL/C already ?

Thanks & Regards
..mkv

- Show quoted text -

> All in all an interesting development that if handled well may benefit
> Informix more than anyone else.

> Nils Myklebust
> NM Data AS
> Norway

> FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html
> (Now with ODBC info under "Third party products".)

 
 
 

What happen Informix? - Y2K Issues in Informix

Post by Helmut Leininge » Sun, 31 Dec 1899 09:00:00


Hi,

DBCENTURY is a phantastic thing and it's true what you said. But you have to take into
account one important fact:

DBCENTURY only helps you in storing the dates "correctly" in the database. It does *not*
help you in the program when you still have (and you do have, because otherwise you
would not need DBCENTURY) 2-digit years. "00" still is less than "99". So you will have
to modify your program logic too to make it Y2K compliant using one of several technics
(expansion, Windowing, mapping etc.)

Regards



> > On Wed, 27 May 1998 08:36:17 -0600, "Gustavo A. Murillo Fuentes"

> > >       One company of software in Costa Rica, associated with Oracle, say without
> > >problem: "We are created one tool for migration since the obsolete Informix
> > >tecnology to Oracle tecnology" and they suggested between lines, what
> > >Informix 4GL have problems with the Y2K!!!.  What happen Informix? :-(

> > 1. There are no Y2K problems with Informix 4GL appart from those you
> > created yourself by using only 2 digts for years in input fields. Even
> > these are solved by Informix in ver. 4.20 and 7.20 of 4GL via the
> > DBCENTURY environement variable. I would assume this company have done
> > something similar.

> Right from the day I started writing any date, I have always used 2
> digit years. This was the CONVENTION. Naturally, most of the programmers
> have used 2 digit years in their code and system design. So we may not
> have used 4 digit year in screen or reports. These may be problems
> created by us but let us not kid ourselves.

> That DBCENTURY will take care of everything may not be entirely true.
> Most of the applications, yes. But applications which deals with date
> which spans more than +-50 years could pose problems. This may  or may
> not be likely in many applications and you are the best judge regarding
> your application.

> Informix does not have any problem in storing dates that belong to
> different centuries. But the problem is what happens when we cross the
> year 2000 with 2 digit year all over in my application.
> Informix gives you DBCENTURY environment variable which can have values
> F - Future, P - Past, C - Closest, R - Current century which is the
> default.

> Let us say if you are having screens which accept 2 digit dates for some
> thing like a date of birth ( past date ),  date of next increment (
> future date ) (when compared to the current date). Suppose the values
> are as follows :
> Date of Birth = 1/1/49   ( 1949 )
> Date of next increment = 1/1/1 ( 2001 )
> Current Date =  3/ 1/ 00 ( 2000 )

> DBCENTURY = P ( Consider past and present century, Chose prior date )
>  Date of Birth = 1/1/1949 and 1/1/2049  Prior date is 1/1/1949
> * Date of next increment = 1/1/1901 and 1/1/2001 Prior date is 1/1/1901
>   stored as 1901
>  DBCENTURY = P will not work for date of next increment

> DBCENTURY = F ( Consider present and future century. Chose future date )
> * Date of Birth = 1/1/1949 and 1/1/2049  Future date is 1/1/2049 stored
> as 2049
>  Date of next increment = 1/1/1901 and 1/1/2001 Future date is 1/1/2001
>  DBCENTURY = F will not work for date of birth

> DBCENTURY = C ( Consider past, present and future century. Chose closest
> date )
> * Date of Birth = 1/1/1949,  1/1/2049, 1/1/2149  Closest date 1/1/2049
>  Date of next increment = 1/1/1901, 1/1/2001, 1/1/2101
>    Closest date is 1/1/2001
>  DBCENTURY = C will not work for date of birth

> DBCENTURY = R ( Consider present century. Chose current century date )
> * Date of Birth =  1/1/2049
>  Date of next increment =  1/1/2001
>  DBCENTURY = R will not work for date of birth

> Note that we can not be flipping environment variable between different
> data entry screens. Now the problem is clearly applications which deal
> with dates > + or - 50 years from current date using 2 digit years. In
> this case year 49 falls outside the 50 year  boundary. Hence same
> DBCENTURY setting may not work for all date columns in your application.

> The simplest solution is USE 4 DIGIT YEARS, so that Informix knows which
> year without having to interpret using DBCENTURY. Now this means, we
> have to look at screen layout to see if we can accomodate 4 digit year
> during entry and CHANGE it. Reporting may not be a problem, since we
> have the common sense to read a 2 digit year on print and interpret the
> correct century. Data transfer between external systems may also pose a
> problem and require CHANGE.

> If we are not changing to 4 digit years, with any of the above DBCENTURY
> setting, we can take care of about half the dates as 2 digit dates, but
> we may have to code some logic to interpret the correct century for the
> others. For example, I could leave DBCENTURY as Current/Closest and put
> some code in after field clause of Date of Birth. This means CHANGE in
> application.

> For date values stored in character or smallint fields it is totally a
> different story. It is like COBOL. I have seen atleast one such Informix
> application.

> THIS PROBLEM MUST EXIST IN ORACLE TOO. There may be tools. But we also
> have tools for Informix or atleast develop if we do not have. We are
> developing some tools for analysis and conversion for fixing Y2K
> problems.

> May be Informix can provide a better fix. A SET CENTURY statement  may
> work which I can plug in for some problem date fields. But this may lead
> to other problems after a certain date ( standard windowing technique).

> We should  think about this Y2K problem to see if we can arrive at a
> better solution and propose to Informix. May be Informix folks have
> already given it too much thought and had arrived at this DBCENTURY as
> the best fix. We represent the Informix world and we really need to
> provide good suggestions.

> I would sincerely recommend changing applications to 4 digit years if
> there are problem date fields. May be, we need to have a NEW CONVENTION,
> read and write 4 digit years.

> If my above interpretation of DBCENTURY is wrong please correct me. I
> have tested the above values by resetting system clock and doing insert
> with different DBCENTURY settings using dbaccess and then did a select
> with DBDATE set as DMY4. And that is how the values got stored. I had
> used 7.22 UC1. Actually I had done this long time back when the feature
> was announced. I will have to test using the latest version of 4GL, IDS
> and ESQL/C to see if it is any different. Has any one tested using 4GL
> and ESQL/C already ?

> Thanks & Regards
> ..mkv

> > All in all an interesting development that if handled well may benefit
> > Informix more than anyone else.

> > Nils Myklebust
> > NM Data AS
> > Norway

> > FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html
> > (Now with ODBC info under "Third party products".)

--
Helmut Leininger

Bull AG / Vienna
Unix Support

This opinion is mine and not necessarily that of my employer.
No guarantees whatsoever.

 
 
 

What happen Informix? - Y2K Issues in Informix

Post by Jamie Nas » Sun, 31 Dec 1899 09:00:00


Quote:

>DBCENTURY = C ( Consider past, present and future century. Chose closest
>date )
>* Date of Birth = 1/1/1949,  1/1/2049, 1/1/2149  Closest date 1/1/2049
> Date of next increment = 1/1/1901, 1/1/2001, 1/1/2101
>   Closest date is 1/1/2001
> DBCENTURY = C will not work for date of birth

I disagree, I think the above will work.  The amount imagine the today was
the 1/1/1998 (just to make it simple).  The difference between 1949 and 1998
is 49 years.  Whereas the difference between 1998 and 2049 is 51 years
therefore 1/1/1949 is what would be calculated for date of birth which means
all dates will be correct.

Jamie

 
 
 

1. Informix 7.2 Y2K Issue

I need some help solving a Y2K issue I have with Informix.  Here's the
situation:

I wrote a front-end system in VB that queries, displays, and updates
multiple tables in Informix.  I am using an ODBC connection.  On queries
that update date fields in the db, I find that sending a date in the
format '01/01/00' is saved in Informix as '01/01/1900'.  I verified in
ISQL this same problem using the identical update query.

My DBA changed the environment variable DBCONFIG to 'F'.  In ISQL, the
problem disappeared.  '01/01/00' was correctly interpretted as
'01/01/2000'.  But when I used my front-end system, it still came up as
1900.

Does anyone have a suggestion other than changing my front-end to accept
4-digit years?  

Thank you,
Bob Trenczer

2. Data Enviornment Child Command Query Update

3. informix tools Y2K issues

4. colors, maybe even html tags in tmemo?

5. Y2K Issues in Informix

6. Check DB Exists / When Created

7. Informix 4.10 Upgrade & Informix ODBC Issues

8. paradox 5 .0 & windows 95

9. INFORMIX 4.1 to INFORMIX 7.X migration issues