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/ _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
