From: Gary SMITH Subject: Re: Oracle 7.3 not Y2K compliant on Digital Unix? Date: 1998/05/05 Message-ID: <354EDE78.3B92BC61@cern.ch>#1/1 Content-Transfer-Encoding: 7bit References: <5u4qPGA1f4S1EwY1@jimsmith.demon.co.uk> <01bd776a$41d10ce0$2207030a@sahmad-pc.mfa.com> <354ed170.4495584@news.demon.co.uk> Content-Type: text/plain; charset=us-ascii X-Complaints-To: news@sunnews.cern.ch X-Trace: sunnews.cern.ch 894361207 281 (None) 137.138.118.74 Organization: CERN Mime-Version: 1.0 Reply-To: Gary.Smith@cern.ch Newsgroups: comp.databases.oracle.server,comp.databases.oracle.misc Eric Junkermann wrote: > On 4 May 1998 14:38:12 GMT, "Saad Ahmad" > wrote: > > >They might be referring to issues like: > >SYS SQL> desc v$transaction > > Name Null? Type > > ------------------------------- -------- ---- > > ADDR RAW(4) > > XIDUSN NUMBER > > XIDSLOT NUMBER > > XIDSQN NUMBER > > UBAFIL NUMBER > > UBABLK NUMBER > > UBASQN NUMBER > > UBAREC NUMBER > > STATUS VARCHAR2(16) > > START_TIME VARCHAR2(20) <<<------ > > > >SYS SQL> update dual set dummy = dummy; > >SYS SQL> select start_time from v$transaction; > >START_TIME > >-------------------- > >05/04/98 09:38:03 > >SYS SQL> rollback; > > > >But I won't sweat over it. > > > > This is **not** a Y2K issue - selecting a date field from anywhere > gets you the default format (which defaults to 2 digit year but can be > changed) unless specified otherwise. If you want a 4-digit year, > specify it and it will be correct. > > To go back to the original post, a 3rd party supplier is no more > likely to be right than anyone else. Ask them for their reasons, and > then get them independantly evaluuated (here would be good). > > Regards, > > Eric The START_TIME column is a VARCHAR2 and not a date. So maybe this is the Y2K issue. -- ************************* Gary Smith CERN, Geneva, Switzerland Email: Gary.Smith@cern.ch Tel: +41 22 7678944 *************************