From: Aleksey Demakov <[EMAIL PROTECTED]> To: Alan Tam <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: [Mono-list] DbDataAdapter.Fill patch Date: Tue, 25 Feb 2003 15:24:56 +0600
So what's wrong with it? I think that a DataAdapter at one time should update only one table. It's absolutely wrong to iterate through all the tables in the DataSet because the DataAdapter contains only one set of update commands while different tables require different commands.
Regards, Aleksey
Alan Tam wrote:The bottom half of the patch has been applied. Thank you.
For the upper half, we may need more discussion. As far as I've observed, the
patch changes the code to simulate Microsoft behavior, which seems to be a
wrong behavior. I wonder if we should follow suit.
Regards, Alan
----- Original Message ----- From: "Aleksey Demakov" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 22, 2003 4:37 AM 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.
Regards, Aleksey
I think nobody here has used VS.NET wizards, extensively. So let me share my experience...
The wizards simply won't allow anyone to make a DBAdapter updatable, if you bring it something more complex than a simple select from where it can find all the mappings automatically.
It's not that we can't make our implementation able to handle more general situations, but MS directs developers in that way and so they may have designed their classes to support ONLY that way of doing things, and compatibility is still a goal of this project, I think.
Show me MS classes doing that kind of multiple table updating, WITHOUT having to dynamically alter what the "Initialize()"-time code has set. Without that I think it's better to handle only single table updates.
Oh, yeah: It is an ugly picture seeing each of my Web Service components in design mode sporting some dozens of DataAdapters, but that is the way with MS Tools, and people from Windowsland, like me, will find it 'natural' and expect it to be so in Mono, too.
Best regards,
Rafael Teixeira Brazilian Polymath Mono, MonoQLE Hacker
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
