executeUpdate "innerhalb" eines Resultsets

[Nachtfalke]

Hallo zusammen,

ich habe mal wieder ein Problem, daß sich per Google nicht lösen liess. Ich habe folgenden Code:

sQuery = myConn.createStatement();
      sInsert = myConn.createStatement();
      rsQuery = sQuery.executeQuery("select code from mytable");
      while (rsQuery.next()) {
        sCode = rsQuery.getString("code");
       
        try {
            sInsert.executeUpdate("insert into logs (code) values (" + sCode + ")");
          } catch(Exception e) {
          }
        }
      }
    } catch (Exception e) {
      Tools.errorPrint(e);
    }

Wenn die Schleife allerdings beim zweiten Mal an rsQuery.next() vorbeikommt, wird diese Exception geworfen:

SQLState:   XCL16
Severity: 20000
Message:  Das ResultSet ist nicht geöffnet. Die Operation 'next' ist unzulässig. Prüfen Sie, ob das automatische Festschreiben inaktiviert ist.
java.sql.SQLException: Das ResultSet ist nicht geöffnet. Die Operation 'next' ist unzulässig. Prüfen Sie, ob das automatische Festschreiben inaktiviert ist.

Hat jemand eine Idee, woran das liegen könnte?

 

[z-mon]

Hallo Nachtfalke,

bekommst du den Fehler auch wenn du das zweite executeUpdate() auskommentierst?

Grüße

 

[Michael...]

Pro Statement kann nur ein ResultSet geöffnet werden/sein.

Steht übrigens auch in der API Doku.

 

[SlaterB]

sind das nicht zwei Statements?
> sQuery = myConn.createStatement();
> sInsert = myConn.createStatement();

 

[Michael...]

Stimmt. Sorry habe wohl zu schnell gelesen.

 

[Nachtfalke]

Wenn ich das executeUpdate auskommentiere, bekomme ich keinen Fehler. Das hatte ich vergessen, zu erwähnen. Aber die beiden Statements sollten doch unabhängig voneinander sein, oder?

 

[SlaterB]

die beiden mit == verglichen ergibt nicht zufällig true, weil myConn eine deiner eigenen Klassen ist die dasselbe Statement 2x zurückgibt?
wenn möglich poste ein vollständiges Testprogramm

ansonsten bleibt dir vorerst, zunächst alle Ergebnisse der ersten Abfrage in eine Liste zu stecken,

 

[Nachtfalke]

die beiden mit == verglichen ergibt nicht zufällig true, weil myConn eine deiner eigenen Klassen ist die dasselbe Statement 2x zurückgibt?

Nope.

java.sql.Connection myConn = DriverManager.getConnection("jdbc:derby:myDB");

Ich werde wohl den Weg mit der Liste gehen.

 

[Michael...]

Im Java Code machst Du ja gar nichts mit den Daten ausser von der DB zu lesen und sie in die DB zu schreiben. Warum machst Du das nicht mit einem Statement oder evtl. sogar direkt auf der DB? (Kenne die Möglichkeiten von Derby nicht)

 

[Nachtfalke]

Innerhalb der Schleife werden noch andere Daten ermitteln. Die werden aber nicht aus der DB, sondern aus einem String gelesen. Der Einfachheit halber habe ich das weggelassen. Es handelt sich nur um diverse Stringmanipulationen und Zuweisungen.

 

[Michael...]

        try {
            sInsert.executeUpdate("insert into logs (code) values (" + sCode + ")");
          } catch(Exception e) {
          }

Lässt Du Dir im Originalcode potentielle Exceptions ausgeben? Eventuell tritt ja eine auf.
Welcher Datentyp steckt hinter code?

Mit Oracle funktioniert sowas evtl. gibt's da bei Derby Einschränkungen.

 

[Nachtfalke]

Ahhhhhhhhh ... manchmal ist man echt betriebsblind. Danke für den Tip. Es war tatsächlich ein fehlerhaftes Insert-Statement.

 

[z-mon]

Ahhhhhhhhh ... manchmal ist man echt betriebsblind. Danke für den Tip. Es war tatsächlich ein fehlerhaftes Insert-Statement.

Manchmal sieht man den Wald vor lauter Bäumen nicht mehr

Nichts desto trotz finde ich die Fehlermeldung dazu nicht wirklich passend und aussagekräftig.

 

[Michael...]

Nichts desto trotz finde ich die Fehlermeldung dazu nicht wirklich passend und aussagekräftig.

Die Fehlermeldung hat schon gepasst, nur hat er sich die entscheidende Fehlermeldung nicht ausgeben lassen ;-) Somit hat er nur die Meldung zum Folgefehler bekommen.

==> leere catch - Blöcke: :noe:

 

[Nachtfalke]

Ich gelobe hiermit feierlich, nie wieder einen Catch-Block leer zu lassen.


Zumindest nicht in der Testphase