Greift CHGTCPA sofort

[Fuerchau]

Laut F1-Hilfe des Kommandos kann man zwar 8K einstellen, ist bei meinen Kunden auch so, aber da steht auch: wählt man eine kleinere Größe wird der Standard angewendet.

Von Paketverlusten bei ODBC (und somit auch JDBC) habe ich während meines Entwicklungslebens mit der IBM i noch nie etwas gehört und ich werde dieses Jahr 64.
Dies könnte also eher auf der JDBC-Seite liegen als auf der IBM i-Seite da der ODBC-Dienst für ODBC oder JDBC derselbe ist.

Wie kommt man auf Paketverlust? Ist es u.U. nicht so, dass im Java-Programm Exceptions ggf. inkorrekt behandelt werden und daher Daten verloren gehen?

[Andreas_Prouza]

Die Java Applikation ist teilweise sehr langsam und Logging nur sporadisch, Dokumentation war damals auch nicht cool.
Habe dann die TCP Packete auf dem Windows Server und der IBM i analysiert und habe dann eben die Auffälligkeit mit den Packeten entdeckt die Verloren gegangen sind.
Aber eben auch bei einem eigenen DB Client (DBeaver) ist dies der Fall.
Klingt alles sehr sehr seltsam.
Java Version 1.8 ist von 2021-04, also jetzt nicht soooooooo alt.

Interessant bei den TCP Packeten war auch: Wenn ich eine sehr große Abfrage starte, dann sind die Packetverluste nur am Anfang, quasi beim Start der Kommunikation, und während des Fetch (ich hab mir 20.000 auf einmal empfangen lassen) gab's keine Packetverluste.

Was ich jetzt nicht alles für eine coole Glaskugel geben würde...

[Fuerchau]

DBeaver ist nun mal auch Java.
Du kannst aber auch Abfragen mal mit Excel (Externe Daten via ODBC) oder Access testen ob es da auch Verluste gibt.
Wie gesagt, ich habe unser BI-Suite, den ETL schon seit 2005, auf ODBC-Bases und es hat sich bisher noch niemand über fehlende Daten beschwert.

Den JT400-Treiber nutze ich in Java-Copymodulen auch schon Jahrzehnte ohne jegliche Probleme.