Y2K and bug/sir 78061

Y2K and bug/sir 78061

Post by Rick Mau » Fri, 27 Nov 1998 04:00:00



6.4/05(axp.vms/03) w/patch 5126.  6.4/06 is not available on Alpha VMS.
(Patch 5126 introduces II_DATE_CENTURY_BOUNDARY.)

If II_DATE_CENTURY_BOUNDARY is not set, and a 2 digit date is entered,
Ingres will assume a century of 1900, without regard to the current century
as defined by the system clock.  This behavior is demonstrated below:

$ show logical ii_date_century_boundary
%SHOW-S-NOTRAN, no translation for logical name II_DATE_CENTURY_BOUNDARY
$ sql y2k
INGRES TERMINAL MONITOR Copyright (c) 1981, 1995 Computer Associates Intl,
Inc.
INGRES ALPHA Version 6.4/05 (axp.vms/03) login  1-JAN-2000 00:00:01

continue
  select now = date('now'), x = date('01-jan-50') \g
* Executing . . .

+---------------------------------------------------+
|now                      |x                        |
|-------------------------+-------------------------|
|01-jan-2000 00:00:01     |01-jan-1950              |
+---------------------------------------------------+
(1 row)
continue

I would like for Ingres to assume the current century as defined by the
system clock.  I do not believe that II_DATE_CENTURY_BOUNDARY can provide
this behavior.

An Ingres tech. forwarded me a document entitled "Ingres & the Year 2000:
Dates from 2000 Onward". I can post this upon request.  An excerpt from the
bottom of that document reads:

Known Problems:
78061 - to set 'current century' based on current year rather than always to
1900 as at present, this affects all cases were year is entered as two
digits including modifying the behaviour of the new II_DATE_CENTURY_BOUNDARY
environment variable.  Fixed via patch.  See the release chart for exact
availability.

The text of the bug is somewhat vague, but I interpret it as saying that
there is a patch available (on some platforms) that provides the behavior I
am looking for.  However, tech. support  tells me that the text above simply
directs the user to set II_DATE_CENTURY_BOUNDARY, and that in my case, the
referenced patch is 5126.

Am I misinterpreting 78061 or is tech. support?  Any information on this is
appreciated.  Thanks!

 
 
 

Y2K and bug/sir 78061

Post by Bill Ada » Sat, 28 Nov 1998 04:00:00


This isn't really relevant to your needs as the II_DATE_CENTURY_BOUNDARY
isn't designed to work in the way you want. I suspect you're going to have
to code around it.
We had to patch our copy of ingres
OpenIngres HP-UX Version OI 1.2/01 (hp8.us5/00) login
with Patch ID 5300 (Previous Patch ID 5242) to make
II_DATE_CENTURY_BOUNDARY work in ABF.
Bill

 
 
 

1. Please Sir, More help sir....(with set relation)....

select a
use employee order ssn
Ok, here's the snippet...

select b
use absence

set relation to ssn into a
set skip to employee

scan
        replace vac_grant with a.vac_ent
endscan

close all

What I want this code to do is, scan thru the table in area b ssn by ssn;  
when it finds a corresponding ssn in the table in area a, replace the field
called vac_grant in area b with the value in field vac_ent in area a.

This set relation stuff is real confusing, and I would GREATLY appreciate any
help with this one.

Thanx much, RH

2. PLS error # 323

3. Ingres optimizer bug - not enough booleans (Access/ODBC) (SIR 42045)

4. Michigan IUG Meeting

5. SQL 6.5 Y2K bug?

6. Just a simple question

7. Importing binaries

8. y2k bug in vbasic 5.0

9. Y2K BUG IN DATEDIFF()

10. Y2K-Bug in Installer?

11. How are you tracking bugs and Y2k Issues?

12. oracle Y2k Bug (server 7.3.4;Developer 2.1)