[Mono-bugs] [Bug 665241] New: System.Data.Common.DataAdapter throws IndexOutOfRangeException
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Tue Jan 18 14:53:05 EST 2011
https://bugzilla.novell.com/show_bug.cgi?id=665241
https://bugzilla.novell.com/show_bug.cgi?id=665241#c0
Summary: System.Data.Common.DataAdapter throws
IndexOutOfRangeException
Classification: Mono
Product: Mono: Class Libraries
Version: 2.8.x
Platform: VMWare
OS/Version: openSUSE 11.3
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Sys.Data
AssignedTo: mono-bugs at lists.ximian.com
ReportedBy: andorbal at gmail.com
QAContact: mono-bugs at lists.ximian.com
Found By: ---
Blocker: No
Description of Problem:
While testing my application on mono, I ran into this exception. It seems that
if a column is specified twice in a SELECT statement using different cased
letters, the IndexOutOfRangeException is thrown. The SELECT works fine using a
DataReader but fails using a DataAdapter to fill a DataTable. I am using
Microsoft SQL Server, so I can only verify that the bug occurs using it.
Steps to reproduce the problem:
1. Create a table in SQL Server using the following SQL:
CREATE TABLE [dbo].[AccountsTest](
[CompanyName] [varchar](100) NULL
)
2. Build a simple application with the following code:
Console.Write("Trying with identical case: ")
Dim sqlCommSucceeds As New SqlCommand("SELECT Companyname, Companyname
FROM AccountsTest", New SqlConnection(<<your_connection_string>>))
Dim sqlAdapterSucceeds As New SqlDataAdapter(sqlCommSucceeds)
Try
sqlCommSucceeds.Connection.Open()
Dim table As New DataTable
sqlAdapterSucceeds.Fill(table)
Console.WriteLine("Success!")
Finally
sqlCommSucceeds.Connection.Dispose()
sqlCommSucceeds.Dispose()
End Try
Console.WriteLine("Trying with different case: ")
Dim sqlCommFails As New SqlCommand("SELECT CompanyName, Companyname
FROM AccountsTest", New SqlConnection(<<your_connection_string>>))
Dim sqlAdapterFails As New SqlDataAdapter(sqlCommFails)
Try
sqlCommFails.Connection.Open()
Dim table As New DataTable
sqlAdapterFails.Fill(table)
Console.WriteLine("Success!") ' Never gets here -- an
IndexOutOfRangeException is thrown!
Finally
sqlCommFails.Connection.Dispose()
sqlCommFails.Dispose()
End Try
Actual Results:
Trying with identical case: Success!
Trying with different case:
Unhandled Exception: System.IndexOutOfRangeException: Array index is out of
range.
at System.Data.Common.DataAdapter.FillTable (System.Data.DataTable dataTable,
IDataReader dataReader, Int32 startRecord, Int32 maxRecords, System.Int32&
counter) [0x00000] in <filename unknown>:0
at System.Data.Common.DataAdapter.FillInternal (System.Data.DataTable
dataTable, IDataReader dataReader) [0x00000] in <filename unknown>:0
at System.Data.Common.DataAdapter.Fill (System.Data.DataTable dataTable,
IDataReader dataReader) [0x00000] in <filename unknown>:0
at System.Data.Common.DbDataAdapter.Fill (System.Data.DataTable dataTable,
IDbCommand command, CommandBehavior behavior) [0x00000] in <filename unknown>:0
at System.Data.Common.DbDataAdapter.Fill (System.Data.DataTable dataTable)
[0x00000] in <filename unknown>:0
at (wrapper remoting-invoke-with-check) System.Data.Common.DbDataAdapter:Fill
(System.Data.DataTable)
at TestApplication.Main.Main () [0x00000] in <filename unknown>:0
Expected Results:
Trying with identical case: Success!
Trying with identical case: Success!
How often does this happen?
This happens every time the SELECT statement is run with the above conditions.
Additional Information:
I purposely used different casing in the successful SELECT statement than what
the column is defined as to show that the problem doesn't seem to be related to
that. I realize that fixing the case and/or only including the column once
would fix the problem, but I think this is unexpected behavior and would be
tough for a developer to find why the exception is getting thrown.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the mono-bugs
mailing list