Hallo und Halli,
ich habe da irgendwie entweder ein Verständnisproblem oder einen Bug.
Eine kleine Routine (JDBC) soll ältere Datensätze aus einer DB löschen.
dafür habe ich folgenden Code

Code java:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

public void reorganize(long defermentPeriod)     {                 m_strBuf.delete(0, m_strBuf.length());                 m_strBuf.append("delete from MEMO_RECORDS").append("\n")                 .append("where TMPST_USED >= ?");                 PreparedStatement pStmtRecord = null;         try         {             pStmtRecord = m_conn.prepareStatement(m_strBuf.toString());                         long dueDate = new java.util.Date().getTime()+defermentPeriod;             pStmtRecord.setTimestamp(1, new Timestamp(dueDate));                         pStmtRecord.execute();               SimpleDateFormat dForm = new SimpleDateFormat("dd.MM.yyyy-HH:mm:ss:SSS");             logger.debug("cut off date:"+dForm.format(new Date(dueDate)));             if (pStmtRecord.getUpdateCount()>0)             {                 logger.info("deleted records by reorganisation:"+pStmtRecord.getUpdateCount());             }         }         catch (SQLException sqlEx)         {             throw new RuntimeException(sqlEx);         }         finally         {             try             {                 pStmtRecord.close();             }             catch (Throwable th)             {                 logger.trace("trouble closing pStmtQRecord!",th);             }         }             }

irgendwie bekomme ich aber nicht ernsthaft die records die ich erwarte. meistens bekomme ich keine reorganisiert, obwohl die zeitliche Vorgabe angewendet auf den Inhalt der Tabelle dies tun müsste.
Muss ich hier die Abfrage anders formulieren, obgleich es doch so auf den ersten Blick richtig zu sein scheint?
Hat jemand da vielleicht auch eine ähnliche Erfahrung gemacht und hat einen Hinweis?

Mit Dankbarkeit für alles was weiterführt

Takidoso

Code :

1	TMPST_USED >= ?

Das müsste doch TMPST_USED < ? sein. Also alle Zeiten welche kleiner(älter) als der Übergebene ist.

Die Variable defermentPeriod muss minus sein, sonst wird durch aktuelle Zeit + X in die Zukunft gerechnet. Aber ich nehme mal an, du willst damit angeben wie alt die Daten sein dürfen.

Daher

Code java:

1	long dueDate = System.currentTimeInMillis()-defermentPeriod;

Ich hab mal das new Date rausgenommen. Ist unnötig, die Millisekunden bekommt man auch vom System

Hi Anime-Otaku,
danke für Deine Revision. Stimmt, irgendwie habe ich es wohl verkehrt herum gemacht, wenn ich mir das nochmal überlege.
Aber drolligerweise bekomme ich nun wieder nichts reorganisiert obgleich ich annehme, dass es eigetnlcih so sein soltle.

mein duedate ist nun 27.09.2009-14:54:41:336 und die Daten stammten alle vom Freitag den 25.09.
Ich habe nun das JDBC-Statement wie folgt:

Code java:

1 2 3 4 5

... m_strBuf.append("delete from MEMO_RECORDS").append("\n")                 .append("where TMPST_USED < ?");   ...

Und ich habe nun auch abgezogen und nicht addiert.

Code java:

1	long dueDate = System.currentTimeMillis()-defermentPeriod;

bekommen tuhe ich aber immer noch nix

Was erwartest du zu bekommen? Die Log-Ausgabe?

Vielleicht hilft ein reindebuggen? Ansonsten sehe ich keinen direkten Fehler.

P.S.: Das PreparedStatement kann im finally null sein, dies sollte geprüft werden. Auch ist es fraglich warum der StringBuffer(warum nicht StringBuilder?) eine Member Variable ist, wenn er am Anfang geleert wird. Du kannst du auch einfach new Date().toString() machen, anstatt mit dem SimpleDateFormatter ran zu gehen.

hi Anime-Otaku,
ich erwarte eigetnlcih, dass von der DB die entsprechenden (in meinem Fall alle) memo_records gelöscht werden.
ich gebe direkt aus, ob er es tut oder nicht (so denke ich zumindest, da ich den UpdateCount abfrage und dieser offenbar 0 ist, denn geloggt wird die Anzahl nur dann, wenn dieser >0 ist.
in anderen Worten irgendwie unlogisch.
den StringBuilder habe ich deshalb als member, da er noch mehrfach in anderen Statements verwendet wird. Es hat nicht viel Sinn aus meiner Sicht immer wieder einen neuen Buffer anzufordern.
Ich hatte irgendwie gedacht man könnte das derby.log so ausgeben lassen, dass es u.a. die verarbeiteten Statements aufweist. Lieder ist es mir noch immer nicht geglückt., trotz der netten Tips in den derby-Refferenzen und manuals :-/
Ich frage mich ernsthaft wo der Wurm ist, der da drinne sein muss.

Ohhhh ha ....
ich bin doch tatsächlich nur zu Betriebsblind heute!
hatte die vollkommen falsche Spalte abgefragt.
kaum macht man es richtig funktioniert es auch schon.

ansonsten herzlichen Dank für den Hinweis auf den anderen Dummkram, den ich machte.