[Interest] QSqlTableModel -- best approach for simple database application?

[Mark Brand]

> I've started browsing the SQL Table Model example in the 4.8 documentation
> (sql/tablemodel/tablemodel.cpp), but I seem to recall some discussions
> suggesting that QSqlTableModel has some limitations or problems that
> might make it not the best choice.

Qt 5 has many improvements for QSqlTableModel, so if it's feasible for 
you, consider using Qt 5. With any luck, Qt 5.0 will be released before 
your application.

If you use Qt 4, it's best to stick with OnManualSubmit edit strategy. 
OnFieldChange and OnRowChange cause the table to be queried after each 
field change or row change, which disrupts navigation in the view, which 
more or less defeats the purpose.

> What approach would people suggest for building such an application? My main goal is simplicity of design and ease of development.  I am not looking to build a "slick" application nor am I particularly rigid in what the user of the tool (primarily me) will have to do to use it.  The tables involved will not be very large -- perhaps hundreds of rows, but probably not thousands.

If you use a database over a network, perhaps with the ODBC driver, be 
sure to try it out before you get too far along. Network latency can 
have bad effects on ODBC driver performance when scrolling.

>
> As a possible enhancement, I might want the data to be edited to be
> displayed in the application based on views in the database, rather
> than raw tables, or possibly in terms of "views" constructed with
> application logic (e.g., various select statements), but I wouldn't
> bother with this if it added much complexity to the application.

You can point QSqlTableModel at a database view. Editing will work if 
the view is updatable. Sqlite and other DBMSs allow you to create 
triggers to make your views updatable.

If you do this, be sure to explicitly setPrimaryKey() so QSqlTableModel 
will know how to construct UPDATE statements. Otherwise, the WHERE 
clause will refer to all columns which doesn't work well for float type.

Models and views must be in the same thread, which means queries are 
executed in the GUI thread. So avoid queries (and views) that take a 
long time to execute.
> Any suggestions for how to approach building such an application
> would be greatly appreciated.
>
> (And if the answer is "copy the sql/tablemodel/ example, and tweak
> it as needed," that would be fine.)

Yes, take a look at the examples. The sqlbrowser example is pretty nice.

Mark