[Hibernate] Record wil niet updaten

[Varienaja]

Ik heb een probleem met hibernate: ik kan wel een nieuw record in de database stoppen (insert into), maar het updaten van het record wil niet. Dit is wat hibernate me verteld:

code:

Hibernate: update BIB_BEZWAAR set version=?, STATE=?, INSERTED=?, MEMO=?, DATUM_DAGTEKENING=?, DATUM_POSTSTEMPEL=?, DATUM_HOORZITTING=?, UITSLAG=?, BESLUIT=?, KENMERK=?, KENMERK_POSTKAMER=?, KENMERK_BELANGHEBBENDE=?, OMSCHR_ANDERSSOORTIG_BEZWAAR=?, GEMACHTIGDE=?, SUBJECTID=?, BEZWAARSCHRIFTID=? where ID=? and version=?
16:11:06,429 DEBUG AbstractBatcher:343 - preparing statement
16:11:06,469 DEBUG BasicEntityPersister:1587 - Dehydrating entity: [geotax.core.Bezwaar#51]
16:11:06,469 DEBUG IntegerType:59 - binding '1' to parameter: 1
16:11:06,469 DEBUG IntegerType:59 - binding '100' to parameter: 2
16:11:06,479 DEBUG DateType:59 - binding '11 July 2005' to parameter: 3
16:11:06,479 DEBUG TextType:52 - binding null to parameter: 4
16:11:06,479 DEBUG DateType:59 - binding '11 July 2005' to parameter: 5
16:11:06,479 DEBUG DateType:59 - binding '11 July 2005' to parameter: 6
16:11:06,489 DEBUG DateType:59 - binding '01 January 0001' to parameter: 7
16:11:06,489 DEBUG StringType:52 - binding null to parameter: 8
16:11:06,489 DEBUG StringType:52 - binding null to parameter: 9
16:11:06,489 DEBUG StringType:59 - binding '4' to parameter: 10
16:11:06,489 DEBUG StringType:52 - binding null to parameter: 11
16:11:06,499 DEBUG StringType:52 - binding null to parameter: 12
16:11:06,499 DEBUG StringType:52 - binding null to parameter: 13
16:11:06,499 DEBUG IntegerType:59 - binding '14611' to parameter: 14
16:11:06,499 DEBUG IntegerType:59 - binding '14611' to parameter: 15
16:11:06,499 DEBUG IntegerType:52 - binding null to parameter: 16
16:11:06,499 DEBUG IntegerType:59 - binding '51' to parameter: 17
16:11:06,499 DEBUG IntegerType:59 - binding '0' to parameter: 18
16:11:06,629 DEBUG AbstractBatcher:266 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
16:11:06,629 DEBUG AbstractBatcher:363 - closing statement
16:11:06,689 DEBUG JDBCExceptionReporter:49 - could not update: [geotax.core.Bezwaar#51] [update BIB_BEZWAAR set version=?, STATE=?, INSERTED=?, MEMO=?, DATUM_DAGTEKENING=?, DATUM_POSTSTEMPEL=?, DATUM_HOORZITTING=?, UITSLAG=?, BESLUIT=?, KENMERK=?, KENMERK_POSTKAMER=?, KENMERK_BELANGHEBBENDE=?, OMSCHR_ANDERSSOORTIG_BEZWAAR=?, GEMACHTIGDE=?, SUBJECTID=?, BEZWAARSCHRIFTID=? where ID=? and version=?]
java.sql.SQLException: ORA-00932: inconsistent datatypes

Ik heb de query nagebouwd en uitgevoerd in sql-plus:

code:

SQL> update BIB_BEZWAAR set version=1, STATE=100, INSERTED='11 July 2005',
  2   MEMO=null, DATUM_DAGTEKENING='11 July 2005', DATUM_POSTSTEMPEL='11 July 2005', 
  3  DATUM_HOORZITTING='01 January 0001', UITSLAG=null, BESLUIT=null, KENMERK='2',
  4   KENMERK_POSTKAMER=null, KENMERK_BELANGHEBBENDE=null, OMSCHR_ANDERSSOORTIG_BEZWAAR=null,
  5   GEMACHTIGDE=12488, SUBJECTID=12488, BEZWAARSCHRIFTID=null where ID=49 and version=0
  6  ;

1 row updated.

Dan lukt het wel gewoon??

Dit is m'n tabel:

code:

SQL> desc bib_bezwaar;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER(9)
 STATE                                              NUMBER(9)
 INSERTED                                           DATE
 VERSION                                            NUMBER(9)
 DATUM_DAGTEKENING                                  DATE
 DATUM_POSTSTEMPEL                                  DATE
 GEMACHTIGDE                                        NUMBER(9)
 MEMO                                               LONG
 DATUM_HOORZITTING                                  DATE
 UITSLAG                                            VARCHAR2(100)
 BESLUIT                                            VARCHAR2(100)
 KENMERK                                            VARCHAR2(10)
 KENMERK_POSTKAMER                                  VARCHAR2(100)
 KENMERK_BELANGHEBBENDE                             VARCHAR2(100)
 OMSCHR_ANDERSSOORTIG_BEZWAAR                       VARCHAR2(800)
 SUBJECTID                                          NUMBER(9)
 BEZWAARSCHRIFTID                                   NUMBER(9)

Ik snap het even niet meer.. iemand anders ideeen?

[edit]Oh, ik vergeet nog iets belangrijks. Dit gaat mis in Oracle8. In Oracle9 of postgresql gaat alles gewoon zoals het hoort.

[ Voor 19% gewijzigd door Varienaja op 11-07-2005 17:48 ]

[Gert]

Misschien dat de gebruikte jdbc driver niet correct werkt met versie 8, maar wel met 9. Als het werkt op de ene database en niet op de andere is de kans klein dat het aan hibernate ligt, tenzij de query niet goed is.

[Verwijderd]

Je debuglog zegt;

code:

update BIB_BEZWAAR set version=?, STATE=?, INSERTED=?, etc...

een inconsistent datatype is niet vreemd als een "?" in een datumveld wilt stoppen.
of heb ik het mis ?

*edit, hij bind de data wel, laat ik me er niet mee bemoeien

[ Voor 27% gewijzigd door Verwijderd op 11-07-2005 23:55 ]

[KurtDB]

Verwijderd schreef op maandag 11 juli 2005 @ 23:51:
Je debuglog zegt;

code:

update BIB_BEZWAAR set version=?, STATE=?, INSERTED=?, etc...

een inconsistent datatype is niet vreemd als een "?" in een datumveld wilt stoppen.
of heb ik het mis ?

*edit, hij bind de data wel, laat ik me er niet mee bemoeien

Dat noemen ze een prepared statement. Hij gaat nadien gewoon de nodige variablen met de index en via de juiste methode (voor de type check) doorgeven aan dezelfde klasse.

[Varienaja]

Gert schreef op maandag 11 juli 2005 @ 23:30:
Misschien dat de gebruikte jdbc driver niet correct werkt met versie 8, maar wel met 9. Als het werkt op de ene database en niet op de andere is de kans klein dat het aan hibernate ligt, tenzij de query niet goed is.

Ik heb de jdbc-drivers voor Oracle8, Oracle9 en Oracle10 al geprobeerd.

(Die vraagtekentjes zijn inderdaad parameters.)

[Verwijderd]

Het klinkt gewoon als een ordinaire bug, al gekeken of het een of andere known issue is?

[rvrbtcpt]

Waarom gebruik je niet HQL?
Je kunt je object toch ophalen en dan de setters gebruiken om de juiste waardes te zetten.
Dan heb je geen gedoe met sql statements meer.
Anders kun je net zo goed een JDBC connectie maken en je SQL statement uitvoeren lijkt me.

[matthijsln]

Frijns.Net schreef op dinsdag 12 juli 2005 @ 11:56:
Waarom gebruik je niet HQL?
Je kunt je object toch ophalen en dan de setters gebruiken om de juiste waardes te zetten.
Dan heb je geen gedoe met sql statements meer.
Anders kun je net zo goed een JDBC connectie maken en je SQL statement uitvoeren lijkt me.

Wat je ziet in het log is de door Hibernate gegenereerde SQL, ik neem aan naar aanleiding van een session.saveOrUpdate(bezwaar)...

Aan de SQL zie ik geen fouten. Wat je nog zou kunnen bekijken is wat er precies over de lijn gaat; Oracle heeft daar vast wel monitoring tools voor denk ik.

[rvrbtcpt]

Dat kan ook natuurlijk.
Mis de source hier even waar het sql statement gemaakt wordt.

Als je idd erachter kan komen over welk veld geklaagd wordt komt je misschien al wat verder.

[TukkerTweaker]

Frijns.Net schreef op dinsdag 12 juli 2005 @ 13:05:
Dat kan ook natuurlijk.
Mis de source hier even waar het sql statement gemaakt wordt.

De source van Hibernate bedoel je

Als je idd erachter kan komen over welk veld geklaagd wordt komt je misschien al wat verder.

Dat is nou juiste de grap, die query loopt gewoon in een query editor.

Ik heb zelf ook soortelijke problemen gehad met Oracle 8. Gebruik je de laatste oracle 8 jdbc drivers? Dit hielp bij mij voor een paar problemen voornamelijk met datumvelden vullen.

[Varienaja]

Nou, ik ben er toch zelf uit gekomen. Het blijkt dat Oracle8 geen null toestaat in een LONG-kolom. Ik heb daarom al m'n getters aangepast, zodat ze lege strings retourneren in plaats van nulls. Probleem opgelost.

[TukkerTweaker]

Varienaja schreef op donderdag 14 juli 2005 @ 14:26:
Nou, ik ben er toch zelf uit gekomen. Het blijkt dat Oracle8 geen null toestaat in een LONG-kolom. Ik heb daarom al m'n getters aangepast, zodat ze lege strings retourneren in plaats van nulls. Probleem opgelost.

Dan snap ik deze

Ik heb de query nagebouwd en uitgevoerd in sql-plus:
code:
1
2
3
4
5
6
7
8
SQL> update BIB_BEZWAAR set version=1, STATE=100, INSERTED='11 July 2005',
2 MEMO=null, DATUM_DAGTEKENING='11 July 2005', DATUM_POSTSTEMPEL='11 July 2005',
3 DATUM_HOORZITTING='01 January 0001', UITSLAG=null, BESLUIT=null, KENMERK='2',
4 KENMERK_POSTKAMER=null, KENMERK_BELANGHEBBENDE=null, OMSCHR_ANDERSSOORTIG_BEZWAAR=null,
5 GEMACHTIGDE=12488, SUBJECTID=12488, BEZWAARSCHRIFTID=null where ID=49 and version=0
6 ;

1 row updated.


Dan lukt het wel gewoon??

opmerking niet.

[Varienaja]

TukkerTweaker schreef op vrijdag 15 juli 2005 @ 11:32:
Dan snap ik deze
[...]
opmerking niet.

Ja, da's apart he dat ik via SQL-Plus wel een null kan opgeven en in een update niet. Erger nog: ergens anders in het programma wordt het record ge-insert met behulp van Hibernate. En ook dan wordt die null-value in die long-kolom gewoon geaccepteerd. Alleen bij updates niet. Ik snap er eigenlijk ook geen hol van, maar ik ben allang blij dat het weer werkt.

Oracle heeft wel meer nare trekjes..