[Qt-interest] QSqlRecord population error checking

[Robert Hairgrove]

Israel Brewster wrote:
> What is the best way to do error checking when populating a QSqlRecord 
> with data? Or, a slightly different question that might solve the first, 
> what is the best way to add and populate a new row on a QSqlTableModel? 
> The goal here is to insert a new record into a QSqlTableModel (and, 
> thus, into the database) populated with data. 
> 
> The method I am using is to create a new QSqlRecord, which I set equal 
> to QSqlTableModel::record() (i.e. an "empty" record from the table). I 
> then use QSqlRecord::setValue on each field that I expect to be there to 
> set the data, and use QSqlTableModel::insertRecord(QSqlRecord) to append 
> the new record to the table. This process works.
> 
> The problem I have is that QSqlRecord::setValue() function has no error 
> checking that I can see. According to the documentation, the setValue 
> function "Sets the value of the field at position index to val. If the 
> field does not exist, nothing happens". It's that "nothing happens" that 
> scares me. In a perfect world, the database in question will always be 
> set up correctly, and this will always work. In the real world, I don't 
> want to assume that-someone may have messed with the database, 
> misspelled a column name, etc. In this case, this process would still 
> work with no errors as far as the program is concerned, but data would 
> be lost- obviously not acceptable. At the moment what I am doing is 
> after each setValue call, I do an inverse value call and make sure the 
> return is what I just set. This seems rather kludgy, however. Is there a 
> better way?

There is definitely a "better way", but it involves a rethink on the 
database side of things. The danger that "someone" will change a column 
name, or a constraint such as changing a column allowing NULLs to NOT 
NULL, is very real and can cause major headaches on the application side 
of things.

The best (and only) solution that I know of is to grant ordinary users 
(i.e. non-DBA users) only SELECT and EXECUTE permissions on the database 
and do any DML (i.e. updates, inserts and deletes) through stored 
procedures. If the database back-end doesn't support permissions or 
stored procedures (i.e. SQLite or MS-Access) then a lot of work has to 
be done on the application side to ensure database consistency.

What is/are your supported back-end RDBMS?