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=76494 --- shadow/76494 2005-12-12 17:36:38.000000000 -0500 +++ shadow/76494.tmp.985 2005-12-12 17:56:30.000000000 -0500 @@ -249,6 +249,52 @@ here for reference, with explanations. ------- Additional Comments From [EMAIL PROTECTED] 2005-12-12 17:36 ------- Created an attachment (id=16205) A patch containing all of my bugfixes since submitting this bug. + +------- Additional Comments From [EMAIL PROTECTED] 2005-12-12 17:56 ------- +Sadly, this diff contains several different fixes. If I had known I +would be fixing several bugs, I would have created some local +branches. All of the bugs I fix only affect sqlite3. + +1) Fixes the memory corruption with named parameters. This corruption +can happen with almost any named parameter transaction, and should +probably escalate this to a "Normal" bug. While fixing this, some +other things changed: + + 1.1) Parameters are now passed using sqlite's unicode functions. This +should make it possible to store 16-bit unicode in UNI-16 sqlite +databases without translation. + + 1.2) If named parameter strings are "long", sqlite uses a callback +function (delegate) to free the memory, which could help performance +with very large (ie 2-3 megabyte) string storage. (It helped me.) This +is not done for small strings as it increases memory fragmentation and +seriously hurts performance. + +2) Compiled sql is not deleted immediately after use. This allows you +to reuse the sql command objects. You can now also reuse the command +objects after changing the query text, as expected. Minor performance +enhancement. + +3) Added code to store binary blobs. Also, the Command now looks at +the DbType associated with a named parameter when saving it, instead +of guessing based on the data type. Just because Sqlite makes wild +guesses about data types doesn't mean we have to. :) Also, this is the +only way to ensure that + +4) The lock timeout code is all commented out. It works, but +performance was so bad I gave up and only access sqlite +single-threaded. Maybe this will be fixed in future versions of +sqlite3, though. + +5) There is still code to map transaction levels to sqlite3 +transaction levels. This is very useful with multiple threads, since +it is very easy to get in a deadlock with the default transaction +level (and multiple threads), in which case sqlite throws an exception +instead of blocking (even if you use a lock timeout). + +Ultimately, sqlite could not meet my performance needs. (That dang +journal file is too slow on windows.) But maybe this code will help +others. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
