I would, for a start, not coalesce a per-row function like date()
. You're better off testing the actual field for NULL as in the following example:
create table a (podate varchar(8));
insert into a (podate) values ('20090101');
insert into a (podate) values ('20090102');
insert into a (podate) values ('20090103');
insert into a (podate) values (null);
commit;
select
case when podate is null
then date('2000-01-01')
else date(substr(podate,1,4) || '-' ||
substr(podate,5,2) || '-' ||
substr(podate,7,2))
end as mydate
from a;
drop table a;
commit;
which outputs:
---------
MYDATE
----------
2009-01-01
2009-01-02
2009-01-03
2000-01-01
DSNE610I NUMBER OF ROWS DISPLAYED IS 4
In your case, the code would look something like:
select case when podate is null
then date('12/31/99')
else date (substr (podate,1,2) || char ('/') ||
substr (podate,3,2) || char ('/') ||
substr (podate,5,2)
end
I haven't tested your specific case since my DB/2 is not set up for US date formats. That's something else to look out for as well. This may not work that well on platforms not using US date formats.
Ideally, dates should be stored in the database as dates, not strings. In other words, the conversion costs should be once when the data enters a table, not the millions of times you're going to extract it. Then your code becomes a simpler and faster:
select case when podate is null
then date('12/31/99')
else podate
end
or, better if you're never going to have that sentinel date as a real date, don't store NULL
s at all. Instead, convert them to date('12/31/99')
as they go into the tables, and use:
select podate
It doesn't get much simpler or faster than that (assuming you're comfortable with a non-NULL sentinel).