anyone else have anything blow up from 2013?
From: John Hurley <johnthehurley_at_gmail.com>
Date: Mon, 14 Jan 2013 15:28:50 -0800 (PST)
Message-ID: <7e1bf01e-050b-4fca-92a7-9149ad85a4b6_at_d10g2000yqe.googlegroups.com>
Minor small application had a table with a DATE column but using it ( via views to cobol ... obviously cobol cannot deal with Oracle DATE column types ) as CHAR(6) field and thinking of it as YYYYMM ...
Date: Mon, 14 Jan 2013 15:28:50 -0800 (PST)
Message-ID: <7e1bf01e-050b-4fca-92a7-9149ad85a4b6_at_d10g2000yqe.googlegroups.com>
Minor small application had a table with a DATE column but using it ( via views to cobol ... obviously cobol cannot deal with Oracle DATE column types ) as CHAR(6) field and thinking of it as YYYYMM ...
Oracle had triggers on views viewing the field as RRMMDD and doing some translation back and forth ( TO_DATE and TO_CHAR obviously along with NVL and defaults ).
It all worked ( feeding in data like '201212' and '200907' and getting back same data until we rolled into 2013.
App blew up feeding in 201301 ( year 2020 month 13 day 01 ) ... looking at quick change back to CHAR(6) from DATE column definition.
No thanks but I had no hand in designing it ... just a time bomb waiting for a 13 Month ... Received on Tue Jan 15 2013 - 00:28:50 CET