FW: [Mono-list] DbDataAdapter.Fill patch
Mon, 27 Jan 2003 14:47:46 +0200
I think Rodrigo or Tim Coleman knows better, but I can try something:
(if) There could be more than one datasource in one DataSet so this is
IMHO more reasonable way. But I'm not realy sure why "one DataAdapter
cannot be be able to perform all the needed updates."?
MSDN says: "Additional result sets are named by appending integral
values to the specified table name (for example, "Table", "Table1",
"Table2", and so on.)." That is you cant be sure the name of the table
MSDN also says: "The Fill operation then adds the rows to destination
DataTable objects in the DataSet, creating the DataTable objects if
they do not already exist."
So there can be already named DataTable which is used?
Anyways, it only needs one test case to solve this problem ;-)
> What do you think? Should this be applied?
> -----Original Message-----
> From: firstname.lastname@example.org
> Behalf Of Aleksey Demakov
> Sent: Tuesday, January 21, 2003 3:37 PM
> To: email@example.com
> Subject: [Mono-list] DbDataAdapter.Fill patch
> Hi all,
> I've found that the DbDataAdapter.Update (DataTable dataTable)
> and Update (DataSet dataSet, string sourceTable) methods
> iterate through all tables of the given dataSet and try
> to update them with this DataAdapter. I believe that
> this is incorrect.
> The dataSet can contain multiple DataTables which are
> Filled using different DataAdapters with different
> select/insert/delete/update commans. Consequently
> one DataAdapter cannot be be able to perform all the
> needed updates.
> Unfortunately, the .NET docs are silent about this
> issue. But I believe that DbDataAdapter.Update methods
> should be symmetric to Fill methods. So as Fill (DataSet)
> method fills only one DataSet table with default
> name "Table", the Update (DataSet) method should
> only update default table. And Update (DataSet, string)
> method should only update the specified table.
> The attached patch fixes also another problem.
> The original code might pass a null DataTableMapping
> value which is then used to create a RowUpdatingEventArgs
> instance. So RowUpdatingEvent handler (for instance
> CommandBuilder) could get null DataTableMapping which
> might be unexpected. The patch makes sure that a non-null
> DataTableMapping is passed.