On Nov 15, 2007 1:43 PM, Michael Bayer [EMAIL PROTECTED] wrote:
yes, this was in my previous email:
We
might look into changing that to an OracleDateTime for autoload=True
on the next release. In the meantime, override your reflected DATE
column with an OracleDateTime type.
though
On Nov 15, 2007, at 1:36 PM, Eric wrote:
Replacing OracleDate with OracleDateTime in oracle.py, and the script
produces:
$ python sa.py
(datetime.datetime(2007, 1, 1, 3, 15),)
Which is what I expect (and what I used to get in 0.3.8, although it's
locally patched and I can't swear that
On Nov 12, 12:24 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Nov 12, 2007, at 11:16 AM, Michael Schlenker wrote:
Hi all,
I'm not sure if its a bug or an intended feature, but the default
behaviour
of sqlalchemy when readingOracleDATE fields is annoying. cx_Oracle
rightfully
The issue is that in essence, both answers are right. ANSI SQL specifies
different data types for DATE fields and DATETIME fields, where DATE fields
do not hold the time portion. Oracle, SQL Server and other database engines
have their own ideas about how best to handle dates / datetimes.
SA
On Nov 12, 2007, at 11:16 AM, Michael Schlenker wrote:
Hi all,
I'm not sure if its a bug or an intended feature, but the default
behaviour
of sqlalchemy when reading Oracle DATE fields is annoying. cx_Oracle
rightfully returns datetime.datetime objects, but Sqlalchemy
truncates this
Michael Bayer schrieb:
On Nov 12, 2007, at 11:16 AM, Michael Schlenker wrote:
Hi all,
your above test means to say if r[0]==now:, else you get a runtime
error.
Right, should copy and paste instead of retype...
When I run it with that fix, the row matches and it prints
Found.
