Will look into that tomorrow. Why isn't "like" appropriate? I'm only specifiy e.g. a date and leaving the time out, so it's not an exact match. BTW, why doesn't 'sysdate' work? Something preventing Oracle from running it through the DBI?
Elda Taluta; Sarks Sark; Ark Arks
| [reply] |
Why isn't "like" appropriate?
Because you can't just make stuff up? "LIKE" is a specific operator for matching strings where "%" can be used in one as a wildcard. It isn't some generic "roughly similar to" DWIM magical operator. Perhaps you should check your documentation?
Now, I often regret when I have to learn more about Oracle (because it usually means I've had to try to use Oracle) and I know Oracle does some rather bizarre things. But I'd still be rather surprised to find out Oracle took the string-comparing LIKE and overloaded it for testing if datetimes were "near".
| [reply] |
As I indicated in my OP the query works in SQL Developer. Maybe it's massaging the code, or maybe newer clients support using "like" in that context. I actually did verify the code in SQL Developer, implying the problem could be a difference in the clients or with DBIx::Simple! You were on the right track (see the updated OP), but there was no need to be so hostile about it!
Elda Taluta; Sarks Sark; Ark Arks
| [reply] |
Why isn't "like" appropriate?
As has been said, a useful LIKE statement needs wildcards (otherwise it's just testing equality). Not to stray too far OT, but you'd also need to cast your date to a string (using to_char). Basically, my advice (for what it's worth) is to stick with comparisons like <= for dates.
The part about the nls setting is more important. You should insure that your DBIx connection spits out dates in the same format as your other Oracle clients. Who knows, you could be trying to compare these to ISO 8601 format.
| [reply]
[d/l]
[select] |
