In addition to QSqlQuery CopperSpice offers three higher-level classes for accessing databases. These classes are QSqlQueryModel, QSqlTableModel, and QSqlRelationalTableModel.

These classes derive from QAbstractTableModel (which in turn inherits from QAbstractItemModel) and makes it easy to present data from a database in an item view class such as QListView and QTableView. This is explained in detail in the section Data in a Table View.

Another advantage of using these classes is that it can make your code easier to adapt to other data sources. For example, if you use QSqlTableModel and later decide to use XML files to store data instead of a database, it is essentially just a matter of replacing one data model with another.

The SQL Query Model

QSqlQueryModel offers a read-only model based on an SQL query.

After setting the query using QSqlQueryModel::setQuery(), you can use QSqlQueryModel::record(int) to access the individual records. You can also use QSqlQueryModel::data() and any of the other functions inherited from QAbstractItemModel.

There's also a QSqlQueryModel::setQuery() overload that takes a QSqlQuery object and operates on its result set. This enables you to use any features of QSqlQuery to set up the query (e.g, prepared queries).

The SQL Table Model

QSqlTableModel offers a read-write model that works on a single SQL table at a time.

QSqlTableModel is a high-level alternative to QSqlQuery for navigating and modifying individual SQL tables. It typically results in less code and requires no knowledge of SQL syntax.

Use QSqlTableModel::record() to retrieve a row in the table, and QSqlTableModel::setRecord() to modify the row. For example, the following code will increase every employee's salary by 10 per cent:

You can also use QSqlTableModel::data() and QSqlTableModel::setData(), which are inherited from QAbstractItemModel, to access the data. For example, here is how to update a record using QSqlTableModel::setData():

The first argument to QSqlTableModel::removeRows() is the index of the first row to delete.

When you are finished changing a record, always call QSqlTableModel::submitAll() to ensure that the changes are written to the database.

When and whether you actually need to call submitAll() depends on the table's edit strategy. The default strategy is QSqlTableModel::OnRowChange, which specifies that pending changes are applied to the database when the user selects a different row. Other strategies are QSqlTableModel::OnManualSubmit (where all changes are cached in the model until you call submitAll()) and QSqlTableModel::OnFieldChange (where no changes are cached). These are mostly useful when QSqlTableModel is used with a view.

QSqlTableModel::OnFieldChange suggests you do not need to call submitAll() explicitly. There are possible drawbacks with this approach:

• Without any caching, performance may drop significantly.
• If you modify a primary key, subsequent changes may not be applied to the correct record.

The SQL Relational Table Model

QSqlRelationalTableModel extends QSqlTableModel to provide support for foreign keys. A foreign key is a 1-to-1 mapping between a field in one table and the primary key field of another table. For example, if a book table has a field called authorid that refers to the author table's id field, we say that authorid is a foreign key.

The screenshot on the left shows a plain QSqlTableModel in a QTableView. Foreign keys (city and country) are not resolved to human-readable values. The screenshot on the right shows a QSqlRelationalTableModel, with foreign keys resolved into human-readable text strings.

The following code shows how the QSqlRelationalTableModel was set up:

See the QSqlRelationalTableModel documentation for details.