2012-03-30 4 views
0

ich in eine fremde Ecke Fall läuft während eines iSeries-Server mithilfe von ADO.NET abfragt und den IBM.Data.DB2.iSeries-Anbieter, der mit Client Access kommt.IndexOutOfRange Ausnahme auf DbDataAdapter.Fill() Datensatz

Ich bin mit einer einfachen Abfrage:

SELECT col FROM table WHERE (col LIKE 'value' OR col LIKE 'value%') FETCH FIRST n ROWS ONLY 

Aber der Adapter gibt eine IndexOutOfRange NUR wenn den Wert, in meinem Fall 102 normalerweise die gleiche Abfrage mit 101 oder 103 Arbeiten ausgeführt werden. Ich habe die Ergebnismenge überprüft, indem ich die Abfrage direkt auf der iSeries ausgeführt habe, sie funktioniert einwandfrei und die zurückgegebenen Zeilen unterscheiden sich nicht von denen, die ich bei der Abfrage mit einem anderen Wert erhalten würde.

Pseudo-Code, der die Abfrage ausgeführt ist wie folgt:

String query = '...' // See above query 

IDbDataAdapter adapter = new iDB2DataAdapter(query, connection) 
DataSet ds = new DataSet() 

adapter.Fill(ds) // IndexOutOfRangeException only a certain values 

Beispiel der Daten, die zurückgegeben werden sollen:

1023 29134 
1023  
1023029039 

Hinweis Das Leerzeichen (und andere Sonderzeichen) wird auch in nicht fehlerhaften Resultsets gefunden, daher bin ich geneigt zu glauben, dass es nicht die Ursache des Problems ist.

Stack-Trace Ausnahme

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) 

aktualisieren Ihr Jungs richtig waren, vielen Dank für Ihre Hilfe. Nach der Migration des Treibers nach v6r1 und der Installation aller Service Packs ist das Problem nicht verschwunden. Am Ende fand ich die beschädigten Daten in meiner Tabelle, indem ich das (dritte) PEEK-Dienstprogramm benutzte, das sich über einige Zeichen beschwerte, die sich in einem ungültigen Bereich befanden (weniger als x'40 'oder gleich x'FF'). Das Schöne an diesem Tool ist, dass ungültige Zeichen automatisch durch "%" ersetzt werden, so dass ich die ungültigen Daten finden konnte, die in jedem anderen Client/Programm als leer angezeigt werden (versuchte ODBC, STRSQL, UPDDTA).

Die ungültigen Zeichen war eigentlich ein Null-Zeichen (X'00'), die die .NET-Treiber nicht zu mögen scheint.

Letztes Update IBM Unterstützung wies mich tatsächlich auf diese APAR (SE35276), die das Problem löst.

Antwort

2

Je mehr ich sehe das Problem, das Sie in ausführen, je mehr ich die .net-Treiber zweifeln. Ich ziehe Daten aus einem Unix-basierten System heraus und stoße häufig auf solche Probleme, wenn der Fahrer etwas bekommt, was er nicht erwartet. Meine Vermutung ist, dass Ihre Zeile # 102 einige Daten enthält, die entweder nicht in den Puffer passen oder einen Datentyp haben, den der Treiber an der Quelle nicht erwartet. Hätten Sie einige Beispieldaten? Wie wäre es mit dem Versuch, 1 Spalte zu einer Zeit zu ziehen, um zu sehen, wo es scheitert?

+0

ich bin schon nur eine Spalte zu ziehen. Weitere Tests haben mich auf Suchanfragen mit '1023' aufmerksam gemacht. Der Datentyp der Spalte ist char, und wenn sie manuell ausgeführt wird, gibt die Abfrage ein normales Dataset zurück (das sind Seriennummern für Geräte, die wir verkaufen). Ich stelle die Daten in meine Frage. –

+0

Hinzu kommt noch, ich meine Client Access aktualisieren, da wir nur die OS V6R1 migriert (obwohl CA V5R4 mit OS V6R1 kompatibel sein soll), um sicherzustellen, dass es kein compat.Ausgabe beenwen CA und das OS –

+1

Ich bin davon überzeugt, dass die Daten in irgendeiner Weise mucked sind. Dies ist in der Regel eine Ausnahme, auf die ich gestoßen bin, wenn meine Quelldaten nicht von guter Qualität sind oder jemand etwas Fettes gefingert hat. Wenn es sich um einen Char-Datentyp handelt, könnte jeder in diesem Feld Leerzeichen einfügen, und Sie würden davon nichts wissen. Ich hoffe, dass ich dir einen Sinn mache. – rvphx

1

Versuchen andere Abfrage-Tools, um zu sehen, ob Sie es Fehler bekommen. Ich bin mit @Rajiv, dass es einige schlechte Daten in der Tabelle gibt. Und verwenden Sie nicht den STRSQL-Befehl auf dem System, der weniger wahrscheinlich Probleme als andere PC-basierte Tools hat. Einer, glaube ich, wird so etwas wie Eichhörnchen genannt.

+0

Also das war es, ungültige Daten. Wäre es zufällig möglich, von einem Tool zu wissen, das eine Datei in ihrer ursprünglichen Form ablegen kann? –

+1

Mit SQL können Sie die Daten in Hex anzeigen. Ich erinnere mich nicht an den Befehl von meinem Kopf, aber eine schnelle Suche erlaubte es mir, sie vor ein paar Monaten wiederzufinden. –

+0

Danke! Es ist HEX(). –

Verwandte Themen