QSqlTableModel and QTableView critics.

[ChrisW67]

I came across several issues using them both, which I think causes one to conclude that those components are not really suitable for real-world database applications. I hope that someone can prove me wrong.

As a blanket statement, I don't think this is warranted. There are quite a few idiosyncrasies that make using them a bit more awkward than they could have been.

For example, if you share a QSqlTableModel on manual submit between two views and edit through one of them you get the situation where edits to existing rows, and new rows, are seen in the other view immediately (no commitAll() required) , but deleted rows remain visible until all changes are committed to the database. In the edited view the deleted row is marked "!" in the vertical header view (if visible). In the other view this is not the case and I've not found another way to determine if a row is scheduled for deletion. Signals can do some of this if he second view is open when the delete is made, but are not useful if you open the second view later.

[Avrohom]

For example, if you share a QSqlTableModel on manual submit between two views and edit through one of them you get the situation where edits to existing rows, and new rows, are seen in the other view immediately (no commitAll() required) , but deleted rows remain visible until all changes are committed to the database. In the edited view the deleted row is marked "!" in the vertical header view (if visible). In the other view this is not the case and I've not found another way to determine if a row is scheduled for deletion. Signals can do some of this if he second view is open when the delete is made, but are not useful if you open the second view later.

How do you delete those rows? Have you tried view->removeRow?

[ChrisW67]

Removing the row is a function of the model, not the view: QSqlTableModel::removeRow().
With OnManualSubmit the removed row remains visible in the view with a marker, so usually I use a QTableView::hideRow() to actually hide the row from view.

In the secondary view the removed row remains visible until QSqlTableModel::commitAll() while other modifications are reflected in real time (i.e. not waiting until they are written to the database). It's this inconsistency that causes me angst.