When you said that it works fine in the SELECT clause - how did you verify it?
It may happen that if you tested an SQL statement in a query tool that the tool retrieved only first N (usually 100 or 1000 or so) records and everything might be OK there. But if the whole result of the SQL was retrieved, you could see an issue there as well even though the syntax you mentioned was used only in the Select clause, not in Where.
Try analyzing all distinct values of
TO_CHAR(JULIAN_DATE + 1900000)
, mainly the last 3 characters, whether there is anything different than numbers between 001 and 365.
SQL in bold below causes an issue. It is worth noting that the field CRPDTA.F0911.GLDGJ below can contain 0 , but the additional filter CRPDTA.F0911.GLPOST ) <> ‘M’ removes these records from being considered
SELECT
to_date(to_char(( CRPDTA.F0911.GLDGJ )+1900000),‘YYYYDDD’)
FROM
CRPDTA.F0911
WHERE
( ( CRPDTA.F0911.GLPOST ) <> ‘M’ )
AND to_date(to_char(( CRPDTA.F0911.GLDGJ )+1900000),‘YYYYDDD’) = ‘31-01-2015 00:00:00’
AND (( CRPDTA.F0911.GLPOST ) <> ‘M’)
I did not use to have good experience with relying on implicit conversions (string to date, etc.). Can you maybe try modifying the WHERE clause and to convert the hardcoded string to a date?
the julian date contained zeroes…but even though I was filtering for this scenario, I had to code for zeroes using a case statement
case
when @Select(GL Dates\Julian GL Date) <> 0
then
to_date(to_char(@Select(GL Dates\Julian GL Date)+1900000),'YYYYDDD')
else to_date(to_char('01/01/9999'),'DD/MM/YYYY')
end