View Full Version : insert 32768
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.
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.
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.
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();
}
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.
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. :)
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:).
Nochmal zum Abschluss dieses Themas: Die hier erhaltene Unterstützung kann man sich nur wünschen.
Das Programm ist natürlich deutlich umfangreicher als hier auszugsweise gepostet. Try und catch war klar. Die elegante Methode Using war neu für mich. So erhielt ich nicht nur eine Lösung für mein Problem, sondern auch eine echte Verbesserung.
Das Lesen von Büchern ist natürlich Voraussetzung. Die echte Lernphase beginnt allerdings erst in der Praxis. Besten Dank und eine gesegnete Weihnacht...