Si tratta di quello che ho trovato qui? http://technojeeves.com/index.php/22...-to-tablemodelOriginariamente inviata da antonello2
Se sì, quel resultSetToTableModel è molto "banale", nel senso che non fa altro che pescare dati (e metadati) dal ResultSet e buttarli nei Vector da passare al DefaultTableModel. Quando il resultSetToTableModel ritorna, hai in mano solo un "normalissimo" DefaultTableModel che ha tutta la struttura dati solo in memoria. Non c'è più alcun aggancio al DB o a quel ResultSet.
Quindi qualunque logica per aggiornare il DB purtroppo è completamente a tuo carico. E visto che il DefaultTableModel è quello fornito dal resultSetToTableModel ... l'unico modo per "sapere" che una cella è stata modificata è tramite il TableModelListener.
Ma questo vuol dire: a) capire che tipo di evento viene comunicato, b) determinare quindi la colonna interessata, c) rintracciare la chiave primaria (e attenzione: se la query per il ResultSet iniziale non ha tirato fuori la chiave primaria ... è un bel problema!), d) fare una query di UPDATE.
Insomma, quel DbUtils.resultSetToTableModel va bene solo se devi principalmente presentare dei dati in forma tabellare e basta.
Ma se invece devi anche aggiornare il DB .... purtroppo ti dovrai "sporcare" un po' le mani facendo ben altro.
Rispondi quotando