ResultSet --> RiesenBug ?

[pro_evo]

hi zusammen,

also das Verhalten meines Programms kann ich mir beim besten Willen nicht erklären ... :

Die Klasse myDBTable bekommt ein ResulSet übergeben und stellt es in einem JTable dar.
Beim Editieren der Strings nun (Integer gehen), erscheinen plötzlich ALLE Strings der Spalte (nicht nur der editierte, sieht man bei z.B. einem Refresh durch minimieren/maximieren) als, anscheinend Objektadressen ?

Ich hab mal alles nötige hochgeladen, koennt es ja mal ausführen, die main ist in der klasse blatt04

http://www.rakatack.intermania.de/up/bug.zip

gruß

 

[Grizzly]

Hi,

hab' das mal überflogen. Ich denke, dass die Zeile

Object o = rs.getObject(column+1);

das Problem sein könnte. ???:L Versuch stattdessen mal, die Texte per getString aus der Datenbank zu holen. Hab' das jetzt allerdings nicht weiter untersucht.

Kann es sein, dass Du noch nicht all zu lange programmierst?

 

[pro_evo]

Hi,

ja an der Zeile liegt es wohl.
Aber ich kann nicht einfach getString drausmachen, die KLasse soll ja für ein beliebiges ResultSet funktionieren.
(generisch)

Offensichtlich kommt vom ResultSet ein Byte[5]-Array als Typ zurück, und das nur bei String.
Weiß der liebe Gott warum :###
Und das ganze aber erst nachdem man was geändert hat ... beim ersten Anzeigen klappt die Methode getValueAt ja auch für die Stringspalten ... wie gesagt nicht begreifbar das ganze für mich ...

gruß

p.s.Ich pg seit letztem Oktober warum ?

 

[Grizzly]

Hi,

ja an der Zeile liegt es wohl.
Aber ich kann nicht einfach getString drausmachen, die KLasse soll ja für ein beliebiges ResultSet funktionieren.
(generisch)[...]

Dann mach' es doch einfach so, dass Du in den Metadaten der Tabelle schaust, welchen Typ die aktuelle Spalte hat.

[...]p.s.Ich pg seit letztem Oktober warum ?

Sieht man halt (noch) am Programmierstil.
Das kommt aber sicher noch mit der Zeit.
Schau Dir einfach mal ein paar Dokumente zu Quellcode Konventionen & Co. an.

 

[pro_evo]

Hi,

ja an der Zeile liegt es wohl.
Aber ich kann nicht einfach getString drausmachen, die KLasse soll ja für ein beliebiges ResultSet funktionieren.
(generisch)[...]

Dann mach' es doch einfach so, dass Du in den Metadaten der Tabelle schaust, welchen Typ die aktuelle Spalte hat.

danke , kein schlechter Tipp,
habs es so versucht (in der getValueAt) :

if (rs.getMetaData().getColumnType(column+1) == java.sql.Types.VARCHAR) {
						return rs.getString(column+1);
					}

Leider keine Änderung ??!
(Wenn man die If Abrage hart macht, also if column == 1 oder 2 und getString returned funktioniert alles komischerweise wie es soll.) ???:L

Die andere Frage is ja warum ich das überhaupt machen muss ? Warum geht getObject beim Ersten anzeigen und nach ner Änderung nur bei String nicht mehr ?

 

[Grizzly]

[...]

if (rs.getMetaData().getColumnType(column+1) == java.sql.Types.VARCHAR) {
						return rs.getString(column+1);
					}

Leider keine Änderung ??!
(Wenn man die If Abrage hart macht, also if column == 1 oder 2 und getString returned funktioniert alles komischerweise wie es soll.) ???:L

Hast Du mal mit

System.out.println(rs.getMetaData().getColumnType(column+1));

den Typ Dir ausgeben lassen? Und dann vielleicht noch ganz am Anfang irgendwo ein

System.out.println(java.sql.Types.VARCHAR);

. Dann kannst Du ja selber vergleichen, was da nicht stimmt.

Die andere Frage is ja warum ich das überhaupt machen muss ? Warum geht getObject beim Ersten anzeigen und nach ner Änderung nur bei String nicht mehr ?

Da bin ich auch überfragt. Könnte mit dem JDBC-ODBC Bridge Treiber zusammenhängen - oder mit dem ODBC Access Treiber.

 

[pro_evo]

Jep das mit dem ColumnType hab ich grad gestetet, er verändert sich :

Es wird nach einer Änderung zu einem BINARY (public static final int BINARY -2) , deshalb kommt er nicht mehr in die If Schleife rein ....

unbegreiflicher Bug ... wie soll das erst bei großen Sachen aussehen ,das hier is ja nur ein Mini-Übungsbeispiel :cry:

 

[Grizzly]

Ich würde einfach ein richtige Datenbank verwenden und kein Access über ODBC über JDBC ODBC Brücke. Probier doch mal bspw. HSQLDB aus.

 

[pro_evo]

hab nun das hier noch in der setValueAt Methode probiert :

				if (rs.getMetaData().getColumnType(column+1) == java.sql.Types.VARCHAR) {
						rs.updateString(column+1, (String)obj);
						System.out.println("dhdhdhhdhdhdhdhdh");
					} 
					else rs.updateObject(column+1, obj);

leider keine Besserung des Effekts

 

[Roar]

hast du nen eignene editor/renderer oder model für deine tabelle geschrieben der dir das versaut?

 

[pro_evo]

hast du nen eignene editor/renderer oder model für deine tabelle geschrieben der dir das versaut?

nein ich habe nur das AbstractTableModel verwendet.
(code oben saugbar )

 

[Bleiglanz]

vergiss das ganze mal und back kleinere Brötchen

es gibt VARCHAR, LONGVARCHAR und CHAR in java.sql.Types, du musst schon ALLE Typen abfragen um das zu erreichen was du willst

und der universal-Abholtyp ist java.lang.String, nicht java.lang.Object! Wenn du also eine unbekannte Spalte aus einem Resultset haben willst, dann liest man die mit getString aus!

 

[pro_evo]

und der universal-Abholtyp ist java.lang.String, nicht java.lang.Object! Wenn du also eine unbekannte Spalte aus einem Resultset haben willst, dann liest man die mit getString aus!

auch z.B. für Interger, Daten oder sonstwas ? hmm außerdem heisst die MUSS Methode :
public Object getValueAt(int row, int column) {

also ich MUSS ein Object returnen !


Hab aber noch 2 Neuigkeiten :
:shock:
- Mit Oracle selbes fehlerhaftes Verhalten !

- Mit PostgreSQL läuft das Programm einwandfrei !


Krass sag ich mal ! Wenn bei sowas Banalem die Treiber schon Mist bauen und das auch noch bei Oracle was man in Unternehmen wohl am wahrscheinlichsten braucht dann gute N8 für "große Sachen" ...

 

[Grizzly]

Zum Einen sind die JDBC Treiber, die die Hersteller / Projekte mitliefern, im Allgemeinen auch was heikles. Zum Anderen würde ich halt mal schauen, was getObject überhaupt zurückgibt - also von welcher Klasse das Objekt ist. Da kann nämlich auch der Hase im Pfeffer liegen. Die Java Standard Klassen sind nämlich teilweise auch nicht ohne und ich hab' shcon öfters um Unzulänglichkeiten der Standard API d'rum rum programmieren dürfen.