Re : Year 2000 Impact on Informix

Re : Year 2000 Impact on Informix

Post by David Co » Sun, 31 Dec 1899 09:00:00



Hi All

Alex Wrote :

>Folks,
>I am not a regular reader of this newsgroup so this may be an FAQ.
>Are there any issues with the Year 2000 problem and Informix.
>I searched the Informix home page looking for white paper or
>any other analysis, found nothing.
>Has anybody seen any info on that?
>Thanks in advance,
>Alex Levinson


As far as I am aware, Informix database engines will have no problems
with
the turnover. However this relief will not extend to 'badly' written
code ie: code
written with date values not including 4 digit years.

As far as more information on this topic is concerned, subscribe to this
group
and keep your eyes peeled.

Although I am sure your mail will spark up a new flurry of messages
regarding
the so called year 2000 time bomb.

Hope that satisfies your curiosity.

Regards

David


Software Consultant
The West Solutions Group
Friends help you move...REAL friends help you move bodies!

 
 
 

1. Year 2000 Impact on Informix -Reply

At first I was going to tell you about Informix 7's method of dealing with
this and that it was not much of an issue.  But then I got to thinking about
it and I'm not sure how SE 5.0 deals with it.  Our main box runs Online 7
and the environment variable takes care of all of our problems but we
also have another box which runs SE 5.0.  So I wonder what the
implications are for this particular installation?

Thanks in advance for any help on this.

The simple fact is that the database itself has *never* had a problem with
the year 2000. The database engine stores dates as integers
representing the number of days since 12/31/1899, and thus is able to
handle 2,147,000,000+ days forward or backward of this date.

Applications, however will have problems if they allow only two-digits
for the year, because the user cannot specify what century a date is in.
The newer engines (i.e., 7.x) allow setting an environment variable as a
default century, but this only circumvents the problem of a date
defaulting to a 20th century year (as would happen with current apps
using 2 digit years in their date fields.

The long and short of the problem is:

First, use only 4 digit year fields. Tell the users that is the length of the
field required, never compromise on that.

Second, upgrade to a 7.x+ version engine that uses the date
environment variable so that your apps can default the year to the
current century for users without them having to input all 4 digits of the
year without any specialized programming. This allows the date field to
act as it does now.

If you don't upgrade to a newer engine, the app won't break if rule #1 is
followed. Users would have to type a 4 digit year, though, unless there
is some customized logic in place. This "problem" is in reality no more
than an inconvenience. Consider the seriousness of year 2000 problems
with other software installations.

Tim

P.S. Did I mention always use a 4 digit year? :)

2. How to copy structure of a table to another database

3. Year 2000 Impact on Informix

4. Help for a novice, Please!

5. Impact of the year 2000 on Oracle systems

6. SQL question

7. YEAR 2000 "BUG": IMPACT ON DATABASES AND DBM

8. Converting mdb to adp

9. Question: Year 2000 bug and impact on databases, database applications, and database management

10. Informix and Year 2000 compliance

11. Informix 6 - Leap Year 2000

12. Year 2000 testing for informix

13. Year 2000 and clarification of Informix official statement