Read the description and look at the example code here. I think you are confused into thinking that -you- have to issue SQL queries to update the database and the view. You don't. The QSqlTableModel::setData() modifies the field at the QModelIndex that is passed in; you optionally call submit() which will both update the database for you -and- cause the table view to update.

If you set the edit strategy to OnFieldChange, then the changes will be submitted automatically when the editing is complete (you do not need to call submit()). If you set the edit strategy to OnRowChange, the changes will be submitted when editing moves to a different row (again, you do not need to call submit()). If the edit strategy is OnManualSubmit, then -you- have to call submit() or submitAll() to force the changes into the database.

The difference among these three strategies is -when- the changes are updated in the database. The QSqlTableModel is a layer that sits between your database and your table view. Editing changes that the user makes in the table view are stored (cached) in the model until they are submitted to the database. Depending on the edit strategy, the changes can be submitted immediately after each field is edited (OnFieldChange), when the selected row changes (OnRowChange), or when your program tells the model to update the database (OnManualChange).

Which strategy you choose depends on how you want your program to interact with the database.

Unless you are doing something special in data() or setData(), I don't think you need to derive from QSqlTableModel at all. The example I linked to uses QSqlTableModel itself; the model, database, and view work together to ensure everything is synchronized.