在使用ADO.NET和客户端访问附带的IBM.Data.DB2.iSeries提供程序查询iSeries服务器时，遇到了一个奇怪的案例。
我正在运行一个简单的查询：
SELECT col FROM table WHERE (col LIKE 'value' OR col LIKE 'value%') FETCH FIRST n ROWS ONLY
但是，在我的情况下，当值为102时，适配器只提供IndexOutOfRange。使用101或103运行相同的查询可以正常工作。我通过直接在iSeries上运行查询来检查结果集，它运行得很好，返回的行与我用另一个值运行查询时得到的行没有什么不同。
运行查询的伪代码如下：
String query = '...' // See above query
IDbDataAdapter adapter = new iDB2DataAdapter(query, connection)
DataSet ds = new DataSet()
adapter.Fill(ds) // IndexOutOfRangeException only a certain values
应返回的数据示例：
1023 29134
1023
1023029039
注意空白字符（和其他特殊字符）也出现在未失败的结果集中，所以我倾向于认为这不是问题的原因。
异常的堆栈跟踪
at IBM.Data.DB2.iSeries.iDB2DataReader.GetDcRow(IntPtr dataPtr, Int32 row, MpDcData[] dcData, UInt32 block)
at IBM.Data.DB2.iSeries.iDB2DataReader.GetValues(Object[] values)
at System.Data.ProviderBase.DataReaderContainer.CommonLanguageSubsetDataReader.GetValues(Object[] values)
at System.Data.ProviderBase.SchemaMapping.LoadDataRow()
at System.Data.Common.DataAdapter.FillLoadDataRow(SchemaMapping mapping)
at System.Data.Common.DataAdapter.FillFromReader(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 startRecord, Int32 maxRecords, DataColumn parentChapterColumn, Object parentChapterValue)
at System.Data.Common.DataAdapter.Fill(DataSet dataSet, String srcTable, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet)
更新你们说得对，谢谢你们的帮助。在将驱动程序迁移到v6r1并安装所有service Pack后，问题并没有消失。我最终使用（第三方）PEEK实用程序在表中发现了损坏的数据，该实用程序抱怨某些字符处于无效范围（小于x'40'或等于x'FF'）。该工具的优点在于，它可以自动将无效字符替换为"%"，因此我能够找到无效数据，这些数据在其他所有客户端/程序中都显示为空白（尝试过ODBC、STRSQL、UPDDTA）。
无效字符实际上是一个null字符（x'00'），.NET驱动程序似乎不喜欢它。
上一次更新IBM支持实际上向我指出了这个APAR（SE35276），它解决了这个问题。
我越是看到您遇到的问题，就越怀疑.net驱动程序。我从基于unix的系统中提取数据，当驱动程序得到一些意想不到的东西时，经常会遇到这样的问题。我的猜测是，您的第102行有一些数据，这些数据要么不适合缓冲区，要么具有驱动程序不希望在源代码中看到的数据类型。你有一些样品数据吗？试着一次拉动一列，看看它在哪里失败了，怎么样？？
尝试使用其他查询工具查看是否出现错误。我同意@Rajiv的观点，表中有一些糟糕的数据。不要在比其他基于PC的工具更不可能出现问题的系统上使用STRSQL命令。我相信有一种叫做松鼠。