# executeUpdate "innerhalb" eines Resultsets



## Nachtfalke (3. Nov 2010)

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 (3. Nov 2010)

Hallo Nachtfalke,

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

Grüße


----------



## Michael... (3. Nov 2010)

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

Steht übrigens auch in der API Doku.


----------



## SlaterB (3. Nov 2010)

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


----------



## Michael... (3. Nov 2010)

Stimmt. Sorry habe wohl zu schnell gelesen.


----------



## Nachtfalke (4. Nov 2010)

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 (4. Nov 2010)

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 (4. Nov 2010)

SlaterB hat gesagt.:


> 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... (4. Nov 2010)

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 (4. Nov 2010)

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... (4. Nov 2010)

Nachtfalke hat gesagt.:


> ```
> 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 (4. Nov 2010)

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


----------



## z-mon (4. Nov 2010)

Nachtfalke hat gesagt.:


> 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... (4. Nov 2010)

z-mon hat gesagt.:


> 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 (4. Nov 2010)

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


Zumindest nicht in der Testphase


----------

