insert 32768

[Armin]

Mit einem C#-Programm übertrage ich Daten aus einem MS-SQL-Server 2008 per SqlDataReader auf eine i5 unter 7.1. Der Insert auf die DB2 funktioniert soweit tadellos. Das Problem liegt in der Datenmenge.
Übertrage ich in eine größere Tabelle erhalte ich einen "Übertragungsfehler" konstant beim 32768ten Datensatz.
Gleiches Problem bei Übertragung in 3 Tabellen unterschiedlicher Satzlänge. Die Verbindung zur i5 wird dabei einmalig aufgebaut.
1. Tabelle 29844 Sätze
2. Tabelle 2 Sätze
3. Tabelle 2921 Sätze --> Abbruch
Auch hier kann der 32768te Satz nicht geschrieben werden.
Diese Zahl sieht für mich nach einer "smallinteger" aus.
Der Feldinhalt scheidet aus, da der Abbruchbereich selektiv übertragen keine Probleme verursacht.
Viiiielen Dank für Eure Hilfe ...

[KingofKning]

An den smallinteger würde ich auch denken, hast Du nicht die Möglichkeit die Daten nach bestimmten Kriterien zu splitten und dann einzeln zu übertragen?GG

[Armin]

Besten Dank für dein Interesse.
Das splitten ist möglich. Allerdings müsste ich dann vermutlich das Connection-Objekt schließen und wieder neu öffnen, da selbst die Übertragung in mehrere Tabellen in der Summe zu diesem Fehler führt.
Die damit verbundene Zeitverzögerung ist die eine Seite, gern würde ich aber auch die Ursache erfahren. Die Aufgabe aus Fremdsystemen Daten zu übernehmen ist doch an sich eine alltägliche Schnittstellenaufgabe. Von daher sollte dieses Problem doch bereits in Erscheinung getreten sein?!

[BenderD]

... das ist einer der Gründe, warum man einen Connection Pool einsetzt und sich pro Transaktion eine Connection vom Pool holt. Bei dem Pool kann man dann Regeln für max usage etc, konfigurieren. Ansonsten sieht das eher nach einem Treiber Problem aus.
BTW: man kann das Geschäft auch von der AS/400 aus machen. Mit ArdGate kann man auf MS SQL Server aus RPG per SQL zugreifen, wie auf eine lokale Datenbank.

D*B

[Fuerchau]

Die Frage ist hier, wie du das in C# regelst.
Ggf. führst du hier (unbewusst?) einen Bulk-Insert aus, der wohl auf 32768, also 32K, Inserts in einem Rutsch beschränkt ist.

Erstelle doch je Tabelle einen einzelnes Command-Object mit einem "Insert into mytable values(?, ?, ...)" und generiere die entsprechenden Parameter.
Dann kannst du in einer Schleife die Parameter befüllen und einen "MyCmd.ExecuteNonQuery()" ausführen. dann sollte es locker auch mit mehr als 32K-Sätzen gehen und ist auch nicht langsamer.

[BenderD]

Bulk insert in mehrere Tabellen?

[Fuerchau]

Ich weiß nicht, wie das mit Automatismen in ADO.NET aufgelöst wird.
Interessant wäre da dann beim Abbruch mal die Fehlermeldung (Exception) des Abbruches.
Ggf. auch mal im Joblog des zugehörigen QZDASOINIT-Job's nachschauen.

Und die letzte Frage:
Welchen DB-Treiber verwendest du in C#?
Den CA-.NET-Treiber gibt es in 2 Versionen. Der Treiber ohne DB-Objektvererbung (aus .NET 1.1) sollte man nicht nehmen, hier wäre der OLEDB/ODBC-Treiber besser.
Mit V6R1 gibt es wohl einen neuen .NET 2.0-Treiber.

[Armin]

Danke für die Unterstützung.
Ich habe eine "public static iDB2Connection" im Main-Modul, die einmalig bei Programmstart die Verbindung aufbaut.
In einem sep. Modul, in 3 sep. Prozeduren beziehe ich mich auf diese Connection. Ich erstelle jedoch in jeder Prozedur ein eigenes Commandobjekt für die 3 DB2-Tabellen, die ich betanken will.
Übergeben werden an die Prozeduren per Referenz der jeweilige MS-SQL-Datareader, mit dem ich dann die DB2-Commandparameter befülle und dann einen SQL-Insert ausführe. "myCommand.ExecuteNonQuery();"

Zwischenzeitlich suchte ich nach dem mir bisher unbekannten Connectionpool. Auf https://publib.boulder.ibm.com/iseri...ctionPool.html
fand ich auch eine Anleitung. Allerdings werden die Commands nicht erkannt. Fehlt mir evtl. eine Using? Aktuell verwende ich die IBM.Data.DB2.iSeries.
Ein Beispiel für einen Newby brauch ich.

[BenderD]

... einen Java ConnectionPool im C#??? eine static Variable für die Connection im main???
=> mir scheint da fehlt Dir ein wenig mehr als ein Beispiel!!!

[Armin]

Der Treiber ist "IBM DB2 for i .NET Provider" Dateiversion 13.0.6.0 vom 7.11.2012
"IBM.Data.DB2.iSeries.dll"
Ich hab alle QZDASOINIT-Job's überprüft und keinen entsprechenden gefunden. Auch im QSYSOPR-Protokoll kein Eintrag. Einziger Hinweis in C#: "Ein Übertragungsfehler ist aufgetreten." Auf der i5 läuft 7.1.

[Fuerchau]

Wenn du dich mit der AS/400 verbindest, muss nach dem MyCnn.Open() ein QZDASOINIT-Job verbunden sein. Ermittelt wird dieser mit "WRKOBJLCK USRPRF *USRPRF", wobei USRPRF dein Anmelde-User sein muss.
Findest du keinen Job, hast du die Verbindung nicht geöffnet.

Der ExecuteNonQuery() wird direkt ausgeführt, der Datensatz müsste direkt in deiner Zieltabelle auftauchen, da wird dann nichts gecached bzw. Bulk-Inserts aufgebaut.

Vor dem Insert musst du hier noch den IsolationLevel festlegen.
Arbeitest du mit Transaktionen bzw. Journalisierung?

"Übertragungsfehler" deutet im Übrigen darauf hin, dass du keine Verbindung zur AS/400 hast oder das Command-Objekt keinen Verweis auf das Connection-Objekt.
Prüfe mal ob du auch tatsächlich einen Open() auf der Connection machst.

Ich verstehe auch nicht, warum du den Fehler auch erst nach 32K Versuchen feststellst.

[Armin]

Den QZDASOINIT gab es auch. Mit dem Abbruch wird er jedoch beendet. Erst nach meiner letzten Nachricht suchte ich nach dem Joblog. Es zeigt jedoch keinerlei Meldung zu Abbruch, Fehler oder Problemen. Aufgeführt sind meine 3 Tabellen mit den geschriebenen Sätzen:
Datei Bibliothek Einheit format art Anzahl Ausw Gem Anz Satz Bereich
SYSROUTINE QSYS2 SYSRO00001 PHY 0 I N. *ACTGRPDFN
QASQRESL QSYS2 QASQRESL LGL 0 I N. *ACTGRPDFN
FEKALES1 AM FEKALES1 FORMAT0001 PHY 29765 O N. 29766 *ACTGRPDFN
FEMEINS1 AM FEMEINS1 FORMAT0001 PHY 1 O N. 2 *ACTGRPDFN
FEDEKLS1 AM FEDEKLS1 FORMAT0001 PHY 2998 O N. 2999 *ACTGRPDFN
QPSRVDMP QSYS *SPOOL WMHYTITL PRT 2 O N. *ACTGRPDFN
QPDSPJOB QSYS *SPOOL DETAIL PRT 184 O JA 1 *ACTGRPDFN

Vor dem insert werden die Tabellen gecleart (CLRPFM über QCMDEXC aus C#). Es gibt weder ein Journaling noch einen Trigger. Mit DSPPFM kann ich das Schreiben in den 3 Tabellen nacheinander sehr schön mitverfolgen. Über Debug sehe ich auch, dass der MS-SQL-Reader korrekt befüllt ist. Beim Excecute.NonQuery tritt dann nahezu ohne Zeitverzögerung der Fehler auf. Die Verbindung steht also nachweislich. Durch den Debug verzögert handelt es sich auch definitiv nicht um ein Zeitproblem, da der Fehler immer reproduzierbar bei Datensatz 32768 auftritt.

PS: an Hr.Bender
Ich schrieb in meiner Problembeschreibung von einem C#-Programm. Sie brachten dann den Connectionpool ins Gespräch. Die static-Connection verwende ich um in verschiedenen Modulen die einmalig geöffnete Verbindung nutzen zu können.