[Mono-bugs] [Bug 77268][Wis] Changed - Sqlite DateTime Parameters Handled Incorrectly

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Wed Jul 19 09:05:12 EDT 2006

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by anmar at gmx.net.


--- shadow/77268	2006-07-19 08:40:02.000000000 -0400
+++ shadow/77268.tmp.9437	2006-07-19 09:05:12.000000000 -0400
@@ -207,6 +207,23 @@
 As long as this isn't fixed on the Sqlite side this is clearly a bug
 for us. Currently we are not able to do any date comparison in SQL or
 use any date functions with these values.
 I think we shouldn't trade correctness for speed.
 What do you think?
+------- Additional Comments From anmar at gmx.net  2006-07-19 09:05 -------
+I'm finishing to test a patch that gives several options to store
+dates through a connection string parameter.  Each of them with their
+speed vs flexibility issues. Conclusions up to now:
+ - String storage in a couple of formats gives compatibility with
+internal sqlite date functions and with the existing odbc driver.
+Though it performs awfully.
+ - Julian day storage is compatible with sqlite date functions but not
+with odbc and does not have performance impact.
+ - Compatibility is not an issue as julian day is stored as double,
+current implementation as integer and string as text. So reading all
+storage formats can be supported without conflicts nor performance hit
+(right now string and integer reads are already supported).
+I'll attach the proposed patch later today. Do I reopen the bug or
+open a new one for this?

More information about the mono-bugs mailing list