>I managed to get around it as follows, but I'd say it is a bug:
>
>What I wanted to do:
>
>case
> when ((p.StartDate <= cast('Today' as date)) and (p.EndDate >= cast('Today' as date))) then
> (cast('Today' as date) + 1)
> else
> p.enddate + 1
> end
>
>What I ended up doing to get around the problem:
>
>case
> when ((p.StartDate <= cast('Today' as date)) and (p.EndDate >= cast('Today' as date))) then
> (cast('Today' as date) + 1)
> --else problem with dates and else section
> when (p.StartDate > cast('Today' as date)) then
> p.enddate + 1
> when (p.EndDate < cast('Today' as date)) then
> p.enddate + 1
> end

Your description sounds strange, Maya. Not that I'd say it is unreasonable that it barks at the first statement (although Date and Timestamp are so similar that I thought you could use them interchangeably, I've no problems running similar queries to yours, but I hardly ever use Timestamp). If enddate is defined as a TimeStamp and you do cast('Today' as Date), then I'd expect the result to be Date, whereas enddate+1 would be TimeStamp (so the alternatives to reporting an error would either be to truncate the timestamp to a date or expand the date to a timestamp). I'd say that a better way to write your case statement would be to either cast('Today' as TimeStamp), or alternatively cast(p.enddate as Date) (or use CURRENT_TIMESTAMP or CURRENT_DATE, although I think they're slightly different from 'Today'), although as said, I am slightly surprised that you cannot use these field types interchangeably.

What surprises me more is that your first query fails, whereas the second succeeds.

Set