Scott Brown <[EMAIL PROTECTED]> wrote: > DROP TABLE IF EXISTS t; > CREATE TABLE t (ts TIMESTAMP, i INT); > INSERT INTO t (i) VALUES(0); > SELECT * FROM t; > > At this point, the timestamp field is un-interpretable. SELECT returns > 0000-00-00 9:01 AM > > UPDATE t SET i = i + 1; > SELECT * FROM t; > > Returns the same thing; 0000-00-00 9:01 AM. JFYI, none of this is correct, > not even the time. > > Finally, SELECT @@sql_mode; returns: > > +------------+ > | @@sql_mode | > +------------+ > | | > +------------+ > 1 row in set (0.01 sec) > > This is MySQL 4.1.0 alpha max nt, btw. > > > Stranger and stranger... > > If I simply convert the column type to DATETIME, all of them are fine, and > appear to have been properly stamped. So, my guess is, the error, or > whatever it is that is happening, is occurring upon retrieval? Is this > actually an ODBC driver issue? I am using the latest MyODBC, beta, I > believe, 3.51.06.00 for Windows... >
I tested with command line client and with my test application that uses ODBC: both worked like a charm. Could you test it with command-line client? -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.net http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Victoria Reznichenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.net <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
