0

I want to refresh a JTable after performing db operations like insert/update/delete without frame reload. Is there a programmatic solution to do so?

Andrew Thompson
  • 168,117
  • 40
  • 217
  • 433
Möbius
  • 17
  • 1
  • 1
  • 9
  • 1
    You could, replace the `TableModel` with a new one which represents the current state of the table. You could update the existing `TableModel` when the operation completes, inserting, updating or removing the row. – MadProgrammer May 06 '14 at 07:24
  • You could create your own `TableModel` by extending `AbstractTableModel` and make use of the `fileTableXXXUpdated` methods as you change the data in order to re-render bits of the table. If the table is large this is the most efficient way as you can refresh individual cells. – Boris the Spider May 06 '14 at 07:29

2 Answers2

3

The answer depends on what type of TableModel you're using...and at what level the events are occuring.

For example, if you have some kind of background Thread or "update" button and want to reload the content from the database, simple create a new TableModel based on the results from the database and apply it to the current JTable, this will update the view automatically.

If you are performing database operations within your application (adding, updating, removing rows), you can provide some kind of notification back to the TableModel and simply update it's content.

For example DefaultTableModel provides addRow, insertRow, removeRow methods. TableModel also provides setValueAt which allows you to change the value of a given cell.

All these methods provide notification back to the JTable that the model is associated with automatically

MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
-2

You should use jtable.getViewport().removeAll() and then refill it again with all data collected from database.

Houssam Badri
  • 2,441
  • 3
  • 29
  • 60
  • 2
    Why not just re-build/re-populate the model – MadProgrammer May 06 '14 at 07:31
  • Why that downvote? Is it not a solution!!, it may not be the best but it is stay an alternative – Houssam Badri May 06 '14 at 08:42
  • 1
    Not the downvoter, but my guess is because 1- it's goes against the grain of the MVC nature of the API and 2- is overly inefficient...just saying...as a guess – MadProgrammer May 06 '14 at 08:44
  • @MadProgrammer aha yeah may be, but could you please say how could that go against the MVC nature of the API? – Houssam Badri May 06 '14 at 21:18
  • 1
    You've removed the view in the anticipation of re-creating it again rather then simply changing the model which is (generally) more efficient, simpler and will achieve what the OP wants. It wouldn't matter if the OP suddenly wanted to show the content from a completely new table/query or simply refresh the current table/query, they'd only have to update the model and the view would follow – MadProgrammer May 06 '14 at 21:45