[Mono-list] Bug (?) in SqliteDataReader

[Nikki Locke]

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 
routine?

> 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.

I agree.

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 
work.

-- 
Nikki Locke, Trumphurst Ltd.      PC & Unix consultancy & programming
http://www.trumphurst.com/