insert 32768

[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]

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.

[Fuerchau]

Das ist schon seltsam.
Wie ist dein IsolationLevel?
Ggf. prüfe in den Verbindungseigenschaften den Commit-Level. Der muss dann auf 0 (ohne Journal) stehen.

Gegen die statische Connection ist nicht unbedingt etwas einzuwenden.

[Armin]

Ich bin wirklich dankbar für Ihre Bemühung.
Die Verbindung läuft nicht über ODBC sondern über ADO. Dabei ist mir keine Möglichkeit für den Commit-Level bekannt. Meine Connection sieht so aus:
public static iDB2Connection myAS400 = new iDB2Connection();
static DB2 myDB2 = new DB2();
myAS400.ConnectionString = "Datasource=AS400; default collection=AM; Pooling=false";
myAS400.Open();

while (myMSSQLReader.Read())
{
string insertString = string.Concat("insert into FEKALES1(SKABT, ...) values(@p1, ...)");
this.myCommand = myAS400.CreateCommand();
this.myCommand.CommandText = insertString;
this.myCommand.Parameters.AddWithValue("@p1", myMSSQLReader["Cod"].ToString());
...
myCommand.ExecuteNonQuery();
}

[Fuerchau]

Da du keine Transaktion startest, wird Autocommit angenommen.
Dein Fehler steckt ggf. in der Schleife!
Ein Kommando benötigst du nicht je Datensatz.
Ggf. ist hier die interne Grenze, dass eine Connection nur max. 32k Command-Objekte aufnehmen kann.
Dies macht aber so keinen Sinn.

Erstelle das Command-Object vor der Schleife und füge die Parameter per Add(Name, Type) an.
in der Schleife kannst du dann die Werte per "mycommand.Parameters(Name).Value = Wert" zuweisen.
Nach der Schleife machst du dann einen myCommand.Dispose().

Bedenke, ein Command-Objekt verweist auf die Connection und umgekehrt. Hier hast du dann deinen Konflikt, da der Garbagecollector das nicht auflösen kannst bis das Connection-Objekt zerstört wird.

Für alle ADO-Objekte musst du Dispose() anwenden oder mittel "Using" klammern.

[Armin]

Hochgeehrter Herr Fürchau,
Volltreffer sag ich! Kurz nach dem Absenden meiner Programmbeschreibung kam mir der gleiche Gedanke. Mit der heißen Nadel umgestrickt, und die Daten kommen nun komplett in einer nie gekannten Geschwindigkeit.
Besten Dank, eine frohe Weihnacht und bleiben Sie der treuen AS400-Gemeinde auch im neuen Jahr erhalten.

[Fuerchau]

Die Geschwindigkeit liegt in der einmaligen Interpretation des Commands mit der anschließend beliebig häufigen Ausführung begründet.
Machst du jedes mal ein neues Command-Objekt, muss die AS/400 jedes mal die Syntax prüfen sowie die Tabelle und Felder ermitteln und checken sowie das Kommando vorbereiten (Preparen) bevor es zur Ausführung kommt.
Es reicht, diesen Vorgang genau 1 Mal zu machen, so dass die nachfolgenden Ausführungen eben beschleunigt werden.
Dies gilt i.Ü. grundsätzlich für jeden SQL-Befehl.

Übrigens, bei deiner Methodik reicht es, eine lokale Variable innerhalb der Prozedur zu verwenden.
Zusätzliche solltest du "Using" verwenden und in einen Try/Catch einbetten.
Using hat den Vorteil, dass das Objekt auch im Fehlerfall (catch) oder bei return automatisch zerstürt wird, da die Dispose-Methode aufgerufen wird.
http://msdn.microsoft.com/de-de/library/yh598w02.aspx

Aber ich denke, du hast hier zur Vereinfachung diese Code-Teile nur ausgeblendet.

[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.