# Update auf Mysql läuft nicht durch



## OnDemand (23. Mai 2017)

Hallo,
ich habe 100.000 Datensätze in einer DB, diese lese ich aus einer Datei immer wieder ein und update die DB.
Seit einigen Tagen fällt mir auf, dass statt 100.000 nur 7000 Datensätze updated werden. Einfach so, ohne Fehlermeldung und Codeänderung. 

Der Code läuft auf Wildfly, Transaction timeout ist auf false gestellt, also unendlich lange transactions (hoffe ich). Da wäre eine Vermutung, dass das einfach abgebrochen wird. Bin grad ein wenig ratlos und weiß nicht welche Richtung ich noch suchen kann. 

Falls es jemanden interessiert 
            stmt.executeUpdate("UPDATE products SET active=1 WHERE products_model=''blabla");


----------



## Thallius (23. Mai 2017)

Bischen mehr Infoprmationen werden wir schon brauchen. Was bedeutet der Query? Führst du diesen 100.000 mal aus mit verschiedenen WHERE Bedingungen oder gibt es 100.000 Datensätze bei denen das WHERE zutrifft oder was auch immer?


----------



## OnDemand (23. Mai 2017)

Genau jeder Datensatz ein Query, das Where variiert bei jedem Datensatz und es gibt immer nur einen Datensatz mit der entsprechenden Where Bedingung


----------



## Thallius (23. Mai 2017)

Und du fängst auch brav alle Excpetion und testest die Rückgabewerte ?


----------



## OnDemand (23. Mai 2017)

jupp! Ich schau nochmal, aber es werden alle sql exeptions abgefangen. Habe auch schon versucht mit b'1' statt nur 1 (Coloumn = BIT) aber daran lag es auch nicht


----------



## stg (23. Mai 2017)

NicoDeluxe hat gesagt.:


> aber es werden alle sql exeptions abgefangen



Und? Gab es welche?


----------



## OnDemand (23. Mai 2017)

nein eben nicht  das läuft ohne probleme bis zu dem 7038. Datensatz und dann ist Ende


----------



## Thallius (23. Mai 2017)

Was ist mit dem Rückgabewert des SQL Befehls? Es sollte ja die Anzahl der geupdateten Rows zurück gegeben werden.


----------



## OnDemand (23. Mai 2017)

Das hab ich noch nie genutzt. Kann man das direkt im Java Code ausgeben lassen?


----------



## stg (23. Mai 2017)

Du hast doch bestimmt mal einen Blick in die Doku geworfen, nachdem ich dich schon dutzende Male darauf hingewiesen habe, dass das unter Umständen sinnvoll sein kann, nicht wahr?

http://grepcode.com/file/repository...tement.java#PreparedStatement.executeUpdate()


----------



## OnDemand (23. Mai 2017)

Nutze keinPrepeared Statemnt, nur ein normales. Und ich meine die 7000 ersten Datensätze klappen ja, ob nun da true oder 1 oder b'1' steht, ist egal, es klappt mit allem. Nur eben ab dem 7001 gehts nicht mehr weiter sondern hört auf


----------



## stg (23. Mai 2017)

NicoDeluxe hat gesagt.:


> Nutze keinPrepeared Statemnt, nur ein normales.


Spielt ja keine Rolle.



NicoDeluxe hat gesagt.:


> Nur eben ab dem 7001 gehts nicht mehr weiter sondern hört auf



Und da solltest du ansetzen und verstehen, was "aufhören" denn genau bedeutet. Werden die Statements abgesetzt? Wie viele Rows werden jeweils tatsächlich upgedatet laut Interface? Wartet dein Program einfach "unendlich lange" auf eine Antwort? usw...


----------



## Joose (23. Mai 2017)

Dann schau dir doch die Dokumenation zum normalen Statement an: http://grepcode.com/file/repository...ava#Statement.executeUpdate(java.lang.String)

abgesehen davon ist es vorteilhafter ein PreparedStatement zu verwenden!


----------



## OnDemand (23. Mai 2017)

Ich weiß, war aber von Anfang an alles auf normales Statemetn, da änder ich jetzt auch nicht mehr viel rum , das geht alles bald auf API. Ich suche da an der falschen Stelle, es hat immer funktioniert, außnahmslos. Da kann es nicht mit dem DB Treiber zu tun haben, sondern an irgendwas anderem. Ich werde das nochmal in einer ruhigen Minuten durchgehen. Danke


----------



## stg (23. Mai 2017)

NicoDeluxe hat gesagt.:


> das geht alles bald auf API.



Ähm?


NicoDeluxe hat gesagt.:


> Da kann es nicht mit dem DB Treiber zu tun haben, sondern an irgendwas anderem.



Ohne, dass du uns Einblick in dein System gewährst, kann man dann aber auch nur raten. Wenn überhaupt.


----------



## Thallius (23. Mai 2017)

Warum fragst du wenn es dich soweiso nicht interessiert? Und den Rückgabewert auszuwerten gehört einfach zu einem guten Stil. Man kann ja nicht einfach davon ausgehen, dass der update geklappt hat. Es gibt unzählige Möglichkeiten warum es nicht klappen kann und Du ignorierst es einfach. Und wenn man Dich drauf hineweißt wilst du uns auch noch erklären das du genau weiß das es daran nicht liegen kann.

Aber was beschwer ich mich. Genau wegen solcher angeblichen "Programmierer" habe ich einen guten Job...


----------



## stg (23. Mai 2017)

Thallius hat gesagt.:


> Genau wegen solcher angeblichen "Programmierer" habe ich einen guten Job...


----------



## OnDemand (23. Mai 2017)

Ihr immer mit eure gute und schlechte Programmierer! Geht am Thema vorbei. Es wurde einfach mal nichts am treiber geändert, was soll ich da jetzt auf Fehlersuche gehen? Rückgabewert habe ich noch nie benutzt, jetzt werde ich es wohl künftig. (Nun habe ich eine Erfahrung gemacht, die ihr wahrscheinlich schon hattet) Macht mich das jetzt zu einem besseren Programmierer? wieder ein Stück an den 100% Perfektion dran juhu!


----------



## stg (23. Mai 2017)

Das Problem ist, dass du oft nicht auf Antworten eingehst, immer wieder ähnliche Fehler machst und Fragen mit unzureichenden Informationen stellst. Das ist sogar so auffällig, dass ich mich an dich als Fragensteller mehr als gut erinnern kann 
Wenn du hier Hilfe suchst, dann solltest du langsam begriffen haben, dass das nur funktioniert, wenn du selbst mitarbeitest.


----------



## OnDemand (23. Mai 2017)

Ja schon aber kann  ja nicht wissen was ihr wissen wollt, wenn keine Frage gestellt wird?
Dein Hinweis in allen Ehren, aber ein Link zur Doku ist keine Frage.
Werde dann erstmal die updateden Rows ausgeben lassen.
Sehe auch, dass das last_update Datum des Datensatzes mehrere Tage als ist bei allen außer der 7000. Von daher vermute ich, dass die garnicht erst abgesetzt werden


----------



## JStein52 (23. Mai 2017)

Sind es immer die gleichen 7000 rows die upgedatet werden ? Gib mal das 7001.te Update per Hand in einer mysql-Konsole ein und guck was passiert.


----------



## OnDemand (23. Mai 2017)

Jupp sind immer die gleichen, der 70001ste funktioniert manuell ebenso die weiteren DS


----------



## JStein52 (23. Mai 2017)

NicoDeluxe hat gesagt.:


> Jupp sind immer die gleichen,


Und zwar die ersten 7000 ?? Kannst du über deine Eingabedaten dafür sorgen dass die rows in anderer Reihenfolge upgedatet werden ? Sind es dann wieder 7000 aber andere ? Loggst du die abgesetzten Statements irgendwie (println() oder sonstwie ) mit ? Es werden also alle 100000 executeUpdate() abgesetzt ? Wurden Einstellungen auf der Serverseite von MySQL geändert ?


----------



## OnDemand (24. Mai 2017)

Hab eben nochmal geschaut, es laufen 7000 durch egal in welcher Reihenfolge.  Habe mit sout mal die DS ausgegeben, joa klappt halt bis zum 7000. Dann macht es NIX bis dann 20 Minuten später eine Meldung aus einem anderen Code erscheint ("Datensatz xx gelöscht") Denn nach den 10000 updates, werden nicht updatede gelöscht. Aber er hat nur 7000 Datensätze aktualisiert, dürfte also noch lange nicht beim löschen angekommen sein. Ich komm einfach nicht dahinter, was das Problem sein kann.

Auf MySql Ebene wurde nur ein neuer User angelegt (unbegrenzte timeouts etc) welcher mit der DB kommuniziert


----------



## OnDemand (25. Mai 2017)

Habe das Problem entdeckt. Es lag am Code, und zwar wird  in einem unterliegendem System ein Parser eingesetzt (opencsv) welcher csv Dateien liest und daraus die Datensätze erstellt die in die DB sollen. Blöderweise  muss die libary Opencsv, einen Bug haben. Denn wenn eine der CSV Zeilen einen fehlerhaften Aufbau hat, bricht die Lib das parsen ab statt nur die Zeile zu überspringen. (Ja es wird exception abgefangen - ArrayIndexOutBounds) aber dannach gehts nicht weiter. Nun hab ich die CSV dort mal mit einem BufferedReader etc einlesen lassen und siehe da es läuft! Danke allen für die Unterstützung und wünsche einen genehmen Männertag


----------



## mrBrown (25. Mai 2017)

NicoDeluxe hat gesagt.:


> Habe das Problem entdeckt. Es lag am Code, und zwar wird in einem unterliegendem System ein Parser eingesetzt (opencsv) welcher csv Dateien liest und daraus die Datensätze erstellt die in die DB sollen. Blöderweise muss die libary Opencsv, einen Bug haben. Denn wenn eine der CSV Zeilen einen fehlerhaften Aufbau hat, bricht die Lib das parsen ab statt nur die Zeile zu überspringen. (Ja es wird exception abgefangen - ArrayIndexOutBounds) aber dannach gehts nicht weiter. Nun hab ich die CSV dort mal mit einem BufferedReader etc einlesen lassen und siehe da es läuft! Danke allen für die Unterstützung und wünsche einen genehmen Männertag


Wie sah denn der Code dafür aus?


----------



## Thallius (25. Mai 2017)

Kann ja nicht sein das die Exception richtig behandelt wurde sonst hättest du ija sofort gewußt was das Problem ist...


----------



## OnDemand (25. Mai 2017)

dummycode: 


```
CSVReader reader = new ....
while (reader.nextline() != null){
try {
Datensatz ds = new Datensatz();
ds.setxx.....

} catch IndexoutofBounds ()
}
}
```

try catch wurde im Nachgang eingefügt, aber es wird schon eher gesplittet. Wenn mehr gewünscht ist, muss ich die Infos besorgen, das ist nicht mein Part gewesen


----------



## mrBrown (25. Mai 2017)

Es gibt Exceptions, die man im Normalfall nicht einfach so fangen sollte - IndexOutOfBoundsE. gehört dazu.
Abgesehen davon ist ein leerer catch-Block schon so ziemlich das Gegenteil von etwas sinnvollen.

ich frag mich aber, wieso da nach dem Abbrechen überhaupt noch mit dem Array gearbeitet wird - aber vllt haben wir auch unterschiedliche Vorstellungen von "Parsen abbrechen"...


----------



## OnDemand (25. Mai 2017)

Ist doch nur dummy code daher leer. Die Zeilen welche fehlerhaft sind, sollen einfach ignoriert werden. Aber das Problem lag an der Lib, denn da ist kein Fehler in der Zeile. Mit dem BufferedReader und split läuft es ganz wunderbar durch


----------



## mrBrown (25. Mai 2017)

NicoDeluxe hat gesagt.:


> Ist doch nur dummy code daher leer.


Na wenn der Dummy-Code nicht dem wirklichen Code entspricht bringt das herzlich wenig...




NicoDeluxe hat gesagt.:


> Die Zeilen welche fehlerhaft sind, sollen einfach ignoriert werden. Aber das Problem lag an der Lib, denn da ist kein Fehler in der Zeile.


Um eben einen Bug in der Lib zeigen oder ausschließen zu können, wäre der Code relevant 
Ich würde spontan nicht davon ausgehen, dass da eine korrekte Zeile zu Problemen führt. Code der das zeigt wäre interessant, dann könnte man 'nen Bugreport schreiben oder das direkt fixen 




NicoDeluxe hat gesagt.:


> Mit dem BufferedReader und split läuft es ganz wunderbar durch


Ein einfaches Split birgt auch recht viel Potential für Bugs


----------

