[Mono-bugs] [Bug 77262][Wis] Changed - [PATCH] Sqlite Support for Multiple Result Sets

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Fri Jun 2 17:33:47 EDT 2006


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 jhill at arcfocus.com.

http://bugzilla.ximian.com/show_bug.cgi?id=77262

--- shadow/77262	2006-06-02 09:14:21.000000000 -0400
+++ shadow/77262.tmp.4739	2006-06-02 17:33:47.000000000 -0400
@@ -124,6 +124,23 @@
 statement?  That is, if a SELECT returns no rows, it won't create a
 result set, which may be confusing when trying to figure out which
 result set is which in the returned DataReader.
 
 Also, it would be good to replace the many occurrences of
 ((SqliteResultSet)resultsets[current_resultset]) with a property access.
+
+------- Additional Comments From jhill at arcfocus.com  2006-06-02 17:33 -------
+There is a difference between those two cases, and this patch accounts
+for that by looking at the number of columns returned from executing a
+statement, rather than rows.  (In SqliteResultSet.ReadpVm,
+returned_data is set once based on the columns returned by the
+preceding ExecuteStatement).  I'd like a more direct test, but this
+seems like that will always be a valid way to determine if results
+were expected.  
+
+You can validate this behavior in the above example by changing the
+sql statement to "SELECT * FROM FirstTable Where 1 = 2; SELECT * FROM
+SecondTable;", and adding a Console.WriteLine directly after the call
+to dr.NextResult();
+
+Good call on ((SqliteResultSet)resultsets[current_resultset]).  Let me
+correct that in the patch and upload shortly.


More information about the mono-bugs mailing list