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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=77268 --- 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 [EMAIL PROTECTED] 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? _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
