[Mono-list] Issues with SqlClient and DataAdapter.Fill() under Linux
vvaradhan at novell.com
Tue Apr 22 09:22:41 EDT 2008
Thanks for the detailed bug report and the test program. Mark, myself
and Nagappan had offline discussions on how to narrow down the issue and
it stands fixed as of rev# 101411 and 101414 in mono-1-9 branch.
His detailed bug report is here:
Revert back in case of any regression or new bugs.
On Wed, 2008-04-02 at 12:12 -0500, Mark Gimelfarb wrote:
> Hello, all!
> I would like to get some feedback from the list before writing up a
> bug on Bugzilla. I apologize for the lengthy post beforehand, but I
> wanted to get as much detail in as I can to make it useful without
> having to go back and forth on the list.
> We've converted an Asterisk.Net-based set of C# IVR code to run on
> Linux. The code was written using VS2k5 and .NET 2.0.
> Asterisk.Net has been modified to run as a daemon and to respond to
> each incoming connection by spawning a thread, which will then access
> MS SQL Server and query some data from it, processing it, and
> returning a resulting AGI command back to Asterisk. All commands and
> responses are text-based, and Asterisk.Net has no dependencies on any
> libraries other than mono runtime and standard class libs.
> The current Linux set up is Mandriva 2007.0 with mono 18.104.22.168
> accessing MS SQL Server 2000 SP4 running on a W2k3 box.
> The process starts by issuing a SELECT query with a
> DataAdapter.Fill(), which returns results just fine. However, a
> subsequent call to a stored procedure which uses INSERT followed by
> SELECT returns no rows (which causes System.IndexOutOfRangeException:
> There is no row at position 0. exception while trying to iterate
> through the DataRow collection coming back from Fill()'ed DataTable ).
> We are using DataAdapter.Fill() from SqlClient to return the data back
> to the calling code. There could be as much as a week between errors
> or just one day or even one hour. The traffic does get heavy
> sometimes, depending on the number of simultaneous calls, but load
> doesn't always seem to be the issue, as we get the error below even in
> relatively low-load conditions. After we received the error 10 or 20
> times in a row, everything seems to come back to normal for a while.
> This error doesn't occur on Windows under .NET 2.0 with exactly same
> Here's a snippet of the stack trace:
> Channel [Zap/1-1] [04/02 10:48:05] Exception caught:
> System.IndexOutOfRangeException: There is no row at position 0.
> at System.Data.DataRowCollection.get_Item (Int32 index) [0x00040]
> in /home/mandrake/rpm/BUILD/mono-22.214.171.124/mcs/class/System.Data/System.Data/DataRowCollection.cs:78
> at Asterisk.NET.FastAGI.Scripts.myRSCIVR.IVRNewCall (System.String
> pcCaller, System.String pcCallee) [0x00066] in [.....]myfile.cs:372
> I omitted the non-relevant path to our code with [...]
> The bottom of the stack is our code trying to iterate through the
> DataTable's DataRows coming back from Fill(). There should always be
> data coming back, as INSERT succeeds every time, even if we get a
> subsequent error. It's the SELECT that returns nothing back (Note,
> it's not that it returns a row with NULLs, it returns no rows
> whatsoever--an empty DataTable).
> Before I submit the Bugzilla report I would like the list's opinion on
> the following:
> 1) Has anyone had this problem before (is there another bug out there
> already)? I searched the Bugzilla, but couldn't find exact same or
> very similar issues. If someone has found a solution or a patch, that
> would be great too :)
> 2) Since the exception we get is not in Fill() itself, but rather
> after that, I would like to see if I can somehow get the source for
> the class lib and put some tracing code around fill and use that
> class lib instead of the stock one to get some tracing within the Fill
> method of the DA, so that my Bugzilla report is most useful to the
> ADO.NET team.
> 3) What all is needed to be submitted with the report to make this
> issue easier to fix?
> This issue is not easy to reproduce at will, so I'm hoping that this
> is all helpful for starters.
> Thank you all in advance for reading this monster of a post.
> Mono-list maillist - Mono-list at lists.ximian.com
More information about the Mono-list