
Originariamente inviata da
andbin
Innanzitutto stai usando "male" JTable e in particolare il DefaultTableModel. I metodi fireXXX in questo caso non li devi invocare tu. È già il DefaultTableModel che "sa" quando/come invocare i fireXXX appropriatamente per aggiornare la "vista" della tabella.
I fireXXX invece vanno gestiti e invocati tipicamente quando si implementa un table model "custom", specializzato, che estende tipicamente direttamente AbstractTableModel.
Riguardo ResultSet.CONCUR_UPDATABLE non mi è chiaro cosa vuoi fare e perché. Il ResultSet.CONCUR_UPDATABLE si può passare ai metodi createStatement/prepareStatement/prepareCall per indicare che si vuole poi ottenere dalla query un ResultSet "aggiornabile", cioè su cui si possono invocare i suoi metodi updateXXX per aggiornare i record (es. updateString, updateInt, updateDouble ecc...).
Dove stanno nel tuo caso le invocazioni di questi updateXXX ?
L'uso di CONCUR_UPDATABLE si utilizza di norma in modo combinato con l'altro parametro resultSetType specificando TYPE_SCROLL_INSENSITIVE oppure TYPE_SCROLL_SENSITIVE. Questo modo d'uso è stato pensato principalmente per le interfacce grafiche. In pratica si tiene il ResultSet "aperto" per molto tempo e mentre l'utente si muove avanti e indietro nella tabella e modifica le celle, il ResultSet viene aggiornato di conseguenza "al volo". È a questo che serve appunto CONCUR_UPDATABLE con TYPE_SCROLL_INSENSITIVE oppure TYPE_SCROLL_SENSITIVE.
E comunque il supporto a CONCUR_UPDATABLE dipende anche dal driver JDBC. E per il driver Connector/J di MySQL mi pare non ci siano problemi a riguardo (ma dovrei andare a verificare, però a memoria mi pare sia assolutamente supportato).
P.S. lo switch sul getColumnClassName è abbastanza bruttino.