[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