[Mono-list] DbDataAdapter.Fill patch
Chris Whelan
cfwhelan@adelphia.net
26 Feb 2003 11:13:56 -0500
--=-bwLqRK2mjADTG5B35wfs
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
I found this blurb regarding the use of the DataAdapter on Microsoft's
MSDN Architecture site at http://msdn.microsoft.com/architecture
...
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, mono-list-request@lists.ximian.com wrote:
> Today's Topics:
>
> 5. Re: DbDataAdapter.Fill patch (A Rafael D Teixeira)
> --__--__--
>
> --__--__--
>
> Message: 5
> From: "A Rafael D Teixeira" <rafaelteixeirabr@hotmail.com>
> To: avd@openlinksw.com, Tam@SiuLung.com
> Cc: mono-list@ximian.com
> Subject: Re: [Mono-list] DbDataAdapter.Fill patch
> Date: Wed, 26 Feb 2003 07:49:52 -0300
>
> >From: Aleksey Demakov <avd@openlinksw.com>
> >To: Alan Tam <Tam@SiuLung.com>
> >CC: mono-list@ximian.com
> >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" <avd@openlinksw.com>
> >>To: <mono-list@ximian.com>
> >>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 <lupus@ximian.com>
> To: mono-list@lists.ximian.com
> 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
>
> --
> -----------------------------------------------------------------
> lupus@debian.org debian/rules
> lupus@ximian.com Monkeys do it better
>
> --__--__--
>
> Message: 7
> Date: Wed, 26 Feb 2003 13:04:50 +0100
> From: Paolo Molaro <lupus@ximian.com>
> To: mono-list@lists.ximian.com
> 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
>
> --
> -----------------------------------------------------------------
> lupus@debian.org debian/rules
> lupus@ximian.com Monkeys do it better
>
> --__--__--
>
> Message: 8
> Subject: Re: [Mono-list] HOWTO Install Mono-0.20 under OS X 10.2
> From: Dick Porter <dick@ximian.com>
> To: mono-list@lists.ximian.com
> 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 <lupus@ximian.com>
> To: mono-list@ximian.com
> 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
--=-bwLqRK2mjADTG5B35wfs
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/1.1.8">
</HEAD>
<BODY>
I found this blurb regarding the use of the DataAdapter on Microsoft's MSDN Architecture site at <A HREF="http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnbda/html/bdadotnetdata4.asp">http://msdn.microsoft.com/architecture</A><BR>
<BR>
...<BR>
<BR>
You can specify parameterized queries or stored procedures for the <FONT SIZE="3"><B>InsertCommand</B></FONT>, <FONT SIZE="3"><B>UpdateCommand</B></FONT>, and <FONT SIZE="3"><B>DeleteCommand</B></FONT> properties of the <FONT SIZE="3"><B>DataAdapter </B></FONT>. The parameters in the parameterized queries or stored procedures correspond to columns in a <FONT SIZE="3"><B>DataTable</B></FONT> object. As a result, the <FONT SIZE="3"><B>DataAdapter</B></FONT> object supports updates against a single table in your database. Hence, when submitting changes to the database, a separate <FONT SIZE="3"><B>DataAdapter</B></FONT> object for every table in the <FONT SIZE="3"><B>DataSet</B></FONT> object will be required. <BR>
<BR>
...<BR>
<BR>
Regards,<BR>
<BR>
Chris Whelan<BR>
<BR>
On Wed, 2003-02-26 at 10:01, mono-list-request@lists.ximian.com wrote:<BR>
<FONT SIZE="3"></FONT><BR>
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373" SIZE="3"><I>Today's Topics:
5. Re: DbDataAdapter.Fill patch (A Rafael D Teixeira)
--__--__--
--__--__--
Message: 5
From: "A Rafael D Teixeira" <rafaelteixeirabr@hotmail.com>
To: avd@openlinksw.com, Tam@SiuLung.com
Cc: mono-list@ximian.com
Subject: Re: [Mono-list] DbDataAdapter.Fill patch
Date: Wed, 26 Feb 2003 07:49:52 -0300
>From: Aleksey Demakov <avd@openlinksw.com>
>To: Alan Tam <Tam@SiuLung.com>
>CC: mono-list@ximian.com
>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" <avd@openlinksw.com>
>>To: <mono-list@ximian.com>
>>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. </FONT>
<A HREF="http://join.msn.com/?page=features/junkmail"><FONT SIZE="3">http://join.msn.com/?page=features/junkmail</FONT></A>
<FONT COLOR="#737373" SIZE="3">
--__--__--
Message: 6
Date: Wed, 26 Feb 2003 12:57:42 +0100
From: Paolo Molaro <lupus@ximian.com>
To: mono-list@lists.ximian.com
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
--
-----------------------------------------------------------------
lupus@debian.org debian/rules
lupus@ximian.com Monkeys do it better
--__--__--
Message: 7
Date: Wed, 26 Feb 2003 13:04:50 +0100
From: Paolo Molaro <lupus@ximian.com>
To: mono-list@lists.ximian.com
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
--
-----------------------------------------------------------------
lupus@debian.org debian/rules
lupus@ximian.com Monkeys do it better
--__--__--
Message: 8
Subject: Re: [Mono-list] HOWTO Install Mono-0.20 under OS X 10.2
From: Dick Porter <dick@ximian.com>
To: mono-list@lists.ximian.com
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 <lupus@ximian.com>
To: mono-list@ximian.com
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</I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-bwLqRK2mjADTG5B35wfs--