[Mono-list] Issues with SqlClient and DataAdapter.Fill() under Linux

Mark Gimelfarb mark at dawebber.com
Wed Apr 2 13:12:53 EDT 2008



   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 1.2.3.1  
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  
code.

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-1.2.3.1/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.

   Regards,

   Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20080402/5887a2ee/attachment.html 


More information about the Mono-list mailing list