View Full Version : Anwendung kann Teildatei nicht öffnen
Hallo zusammen,
ich möchte mal wieder aus einer VB.Net- Anwendung Buchungsdaten an unsere Finanzbuchhaltung DKS übertragen. Dafür gibt es eine Datei S8. Seine Buchungsstapel muss man in eine Teildatei speichern. Das klappt soweit ganz gut. ich mache es wie in diesem Thread (http://newsolutions.de/forum-systemi-as400-i5-iseries/system-i-hauptforum/11078-teildatei-erstellen.html) .
Wenn ich jetzt in der DKS die Übernahme starte, erhalte ich die Meldung:
Buchungstapelteildatei MEINEDATEI nicht verfügbar und daher nicht verarbeitet.Das DKS Handbuch sagt dazu, dass die Datei nicht exklusiv zugeordnet werden konnte.
Ich finde aber keine Satzsperren oder ähnliches. Die Teildatei ist vorhanden und enthält auch Daten.
Kann ich irgendwie prüfen, warum das so ist?
cu
Hallo,
vielleicht hilft Dir der Befehl WRKOBJLCK weiter.
Damit kann man prüfen ob für eine Teildatei
eine Sperre vorhanden ist.
Gruß
Michael
DKS möchte die Datei für sich haben.
Allerdings hält deine VB.NET-Anwendung die Datei wohl noch im Zugriff, deine Anwendung läuft also noch.
SQL schließt die Datei erst, wenn du die Verbindung trennst.
Hallo,
ich mache im Prinzip folgendes:
Dim cn as New OledbConnection("Provider=IBMDA400;...")
Dim cmd as New OledbCommand(sql,cn)
cmd.executeNonQuery
...
cmd.dispose
cn.close
cn.dispose
Aber ich schau's noch mal durch.
WRKOBJLCK zeigt keine Sperren an.
cu
WRKOBJLCK -> F6
Dann siehst du erst die Teildateien und wer diese sperrt.
Bei F6 sagt es F- Taste zur Zeit nicht erlaubt, aber ich habe F4 und die Teildatei angegeben. Dann kommt diese Ausgabe:
Sperr-
Ausw Teildatei Job Benutzer art Sperre Status Gem.
OXIDTRM QZDASOINIT QUSER MBR *SHRRD HELD
DATEN *SHRRD HELD
Ist das meine VB- Anwendung?
Das Problem sind allerdings noch die QZDASOINIT-Job's (ODBC-Zugriffe).
SQL hält die ODP's auch nach Close offen.
Durch das Schließen der Verbindung wird zwar der QZDASOINIT-Job getrennt, aber nicht beendet !
Die nächste Verbindung such sich einen getrennten Job und verbindet sich mit diesem wieder. Erst wenn keiner Verfügbar ist, wird ein neuer Job initiiert.
Solange also der Job tatsächlich nicht beendet wird, sind die Ressourcen noch belegt!
In den Verbindungseigenschaften muss man dafür dann "Lazyclose" dekativieren (wie der Eintrag genau aussieht musst du mal suchen).
Ich habe diesbezüglich nämlich noch ein anderes Problem:
Sind auf dem System mehrere Sprachen installiert, wird die entsprechende QSYS29xx abhängig vom User vorgeschaltet.
Da aber eine QSYS29HH (HH-Hauptsprache) meist nicht existiert, scheitert der CHGSYSLIBL und die zuletzt eingestellte Sprache bleibt bestehen.
Fehlermeldungen erhält man dann in der Fremdsprache.
Lösung: eine leere QSYS29HH (z.B. QSYS2929 für Deutsch) erstellen.
Hallo und Danke,
ich habe gerade ein Redbook zum Provider gefunden. Mal sehen, ob ich etwas zu 'lazyclose' finde.
Ich wünsche erst einmal ein schönes Wochenende.
Noch einer hinterher :)
Könnte eventuell mit Connection Pooling zu tun haben.
The provider uses the ConnectionString as a key to determining whether a connection can be reused out of the connection pool. For connection pooling to work, the ConnectionString for the connection must be identical to a ConnectionString in the pool. If the ConnectionStrings
are not identical, then the connection will not be taken from the pool; instead, a new pool will be created and the new connection will be taken from the new pool. Connection pooling is discussed in greater detail in 4.7.6, “Connection pooling” on page 143.
Das ist per Default aktiv - man kann es aber abschalten.
Das teste ich heute Abend.
cu
Das habe ich auch schon getestet, ändert aber nichts an der QZDASOINIT-Problematik. Diese bleibt bestehen.
Außerdem habe ich festgestellt, dass der Connection-Pool anwendungsspezifisch ist, also nicht systemweit gilt.
Wenn also ein Anwendung eine Verbindung schließt, wird sie dem lokalen Pool zugeordnet, beim nächsten öffnen aus dem Pool entnommen.
Wird die Anwendung beendet, ist auch der Pool weg.
Für den IBMDA400 konnte ich da allerdings nichts finden:
IBM i Support: Software Technical Document : 23062121 (http://www-912.ibm.com/s_dir/slkbase.NSF/00e42b791a3dab7b862565c9004ec1af/c52e46013ce1ded286256a3b006a38c5?OpenDocument)
Diese Option scheint es nur für den ODBC-Treiber zu geben (ist in meinen Augen sowieso die bessere Wahl).