...
You can specify parameterized queries or stored procedures for the InsertCommand, UpdateCommand, and DeleteCommand properties of the DataAdapter . The parameters in the parameterized queries or stored procedures correspond to columns in a DataTable object. As a result, the DataAdapter object supports updates against a single table in your database. Hence, when submitting changes to the database, a separate DataAdapter object for every table in the DataSet object will be required.
...
Regards,
Chris Whelan
On Wed, 2003-02-26 at 10:01, [EMAIL PROTECTED] wrote:
Today's Topics: 5. Re: DbDataAdapter.Fill patch (A Rafael D Teixeira) --__--__-- --__--__-- Message: 5 From: "A Rafael D Teixeira" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Mono-list] DbDataAdapter.Fill patch Date: Wed, 26 Feb 2003 07:49:52 -0300 >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 --__--__-- Message: 6 Date: Wed, 26 Feb 2003 12:57:42 +0100 From: Paolo Molaro <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Mono-list] Installation error on Linux On 02/25/03 Hans Hermawan wrote: > I am having a problem when trying to install Mono on my linux system (Red Hat 8.0). I hope somebody can help me. > I manage to run the make, but receive this error message. Seems like some files missing. > gcc -o monoburg ./monoburg.c parser.c > -I../../../../lib/glib-2.0.6 > -I../../../../lib/glib-2.0.6/. > -I../../../../lib/glib-2.0.6/./glib -I. > ../../../../lib/glib-2.0.6/glib/.libs/libglib-2.0.la > ../../../../lib/glib-2.0.6/glib/.libs/libglib-2.0.la: > file not recognized: File > format not recognized > collect2: ld returned 1 exit status Make sure you're not running out of disk space. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better --__--__-- Message: 7 Date: Wed, 26 Feb 2003 13:04:50 +0100 From: Paolo Molaro <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Mono-list] HOWTO Install Mono-0.20 under OS X 10.2 On 02/25/03 Gerry Shaw wrote: > Problems and Quirks > > * Getting the correct glib and pkgconfig took a bit to figure out) > * The 'mono' program doesn't appear to be installed or built but there > is a man page and there is a mono program when I use the Linux rpm's mono is the JIT, it's not built for ppc systems since it's x86-specific. The new JIT will build on macosx. Just use mint instead of mono. > * When running any C# program (ie, mcs) I get the following warning > message: > > [alpine:~/Projects] gerry% mint HelloWorld.exe > > ** (HelloWorld.exe:16643): WARNING **: Using non-atomic functions! You can safely ignore the warning for now. > * somebody to review this and point out all the mistakes Looks good to me. > * somebody to verify that they can get mono running under OS X I'm building from cvs, so if you have the correct packages install it should build out of the box. > * fix for the non-atomic functions. I think it's something to do with > the POSIX threads under OSX but could be totally off base) It's not related to posix threads. I think someone promised to provide an implementation for those two little functions (details on how to implement them are in the appendix to the powerpc processor manual). If nobody gets to it, I'll write the functions in the next few days. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better --__--__-- Message: 8 Subject: Re: [Mono-list] HOWTO Install Mono-0.20 under OS X 10.2 From: Dick Porter <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Organization: Date: 26 Feb 2003 12:36:41 +0000 On Tue, 2003-02-25 at 17:24, Gerry Shaw wrote: > * When running any C# program (ie, mcs) I get the following warning > message: > > [alpine:~/Projects] gerry% mint HelloWorld.exe > > ** (HelloWorld.exe:16643): WARNING **: Using non-atomic functions! > Hello, World! > > * fix for the non-atomic functions. I think it's something to do with > the POSIX threads under OSX but could be totally off base) There are some atomic compare-and-swap functions, but those need platform-specific assembly. The warning is telling you that there is no support there for ppc (until someone writes it) so the functions are being emulated in a non-atomic fashion. - Dick --__--__-- Message: 9 Date: Wed, 26 Feb 2003 14:23:06 +0100 From: Paolo Molaro <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [Mono-list] ikvm and Mono 0.20 On 02/25/03 Jeroen Frijters wrote: > * The --noinline and --share-code switches are still required, because > otherwise Mono will run the .cctor methods to early (and, by my reading, > the Mono behavior is not allowed by the ECMA spec) This issue will get fixed in the new JIT: we should be able to not inline a method if the act of inlining causes the a type constructor to be run that wasn't run already. But I'll need to review the issue with the spec. If you can provide a test case, that would be appreciated. > * StackFrame.GetFileName() returns "<unknown>" instead of a null > reference when the filename isn't known I have a fix for this, will commit shortly. > * I get an assertion failed: ** ERROR **: file jit.c: line 486 > (mono_store_tree): assertion failed: (s->svt != VAL_UNKNOWN) aborting... Known bug in the old JIT: the new one handles this fine as Zoltan pointed out. lupus
