[Mono-list] Bug (?) in SqliteDataReader
nikki at trumphurst.com
Fri May 26 05:30:03 EDT 2006
Joshua Tauberer wrote:
> Nikki Locke wrote:
> > So I tried some code to insert a DateTime in a parameter. I used the
> > following code...
> > string sql = "insert into tester (testdate) values (?)";
> If you use a named parameter, i.e. ?var, it should work. Unnamed
> parameters weren't implemented. (I just committed a fix for that.)
What you suggest does not work. I looked up the syntax, and the correct syntax is
":var". This appears to work (although, obviously, the DateTime.Parse bug still
applies). Interestingly, it doesn't work with Finisar.SQLite!
> > I think that, in order to avoid breaking existing code, the default should be much
> > as it is now, EXCEPT do not convert strings to DateTimes in ReadpVm
> > (SqliteDataReader, about line 188). That would stop it giving an exception when a
> > string is inserted in a DateTime. It would also prevent the DateTime getting
> > converted back into a string by the DataTable (which is what makes the original
> > value unrecoverable).
> Well, what makes the original value unrecoverable is an independent bug
> in DateTime.Parse (for reference: it is parsing strings like 02/01/2005
> with the U.S. format when the current culture is UK). Importantly,
> knowing where the bug is means the workaround is in your own code that
> parses the contents of the DataTable.
Sorry, I don't think I understand. Are you suggesting I write my own date parsing
> The second work-around was to have GetSchemaTable return DateTime where
> possible, so that the DateTimes the SqliteClient is already parsing
> don't get converted back into strings that need parsing in user code.
> Despite my earlier objections, this seems like a reasonable thing to do.
Oh good - my constant nagging has convinced you then :-)
> The third word-around is to stop parsing strings to DateTimes in
> SqliteClient. Given this changes the data types people get back from
> the SqliteDataReader, I'm very hesitant to change this except through a
> connection string parameter.
Well, the suggested behaviour is more consistent, less prone to unexpected exceptions,
and avoids existing problems (e.g. what do you think happens to a string which contains
something parseable as a DateTime, plus some additional information?). It should at
least be an option. Personally, I think it should be the default.
> But these are all workarounds and it would be nice to just fix DateTime
> before proceeding.
However, having studied the code for the DateTime parsing, I see from the comments that
this bug is deliberate (to the extent that the necessary information about the likely
DateTime formats to be encountered in a Culture has a FIXME: not supported comment).
I would try to offer a patch for it myself, but I'm at a bit of a loss how it should
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
More information about the Mono-list