Retrieving a stored QSqlResult throws an access violation error.

[mmassaro]

I am implementing a custom list model which inherently retrieves data from a Sqlite3 database. In the constructor of the model, I thought to "cache" all the rows of the table I'm interested in (it's fixed and small) in a private QList<QSqlRecord> from a QSqlQuery local to the constructor of the model. My implementation of data() then simply would retrieve the i-th element of that list via list.at(index.row()).

This point makes my application crash, and the debugger tells me that this is an access violation exception. Am I not supposed to store copies of QSqlRecord? Do they get deleted when the QSqlQuery with which I generated them goes out of scope?

[sierdzio]

Are you sure the exception comes from QSqlRecord and not from QList (it's possible you are trying to access row number greater than the size of your list).

And about storing QSqlRecord - I can't find any confirmation in the documentation, but my gut feeling is that they can't be stored. First make sure your QList is OK, though.

[JonB]

@mmassaro
Intuitively, but not based on any evidence, like @sierdzio I would say that a QSqlRecord must contain a reference to the QSqlQuery it came from. If you look at all the methods you can call on a QSqlRecord to get information about the field columns, I would have thought it must get that from the query result. Otherwise if you had 1,000 records they would each have to have their own information about every field.

So my guess is that when you let the QSqlQuery go out of scope the QSqlRecords are left pointing to nonsense, and when they try to access that internally you get a crash.

You would have to turn the QSqlRecords into their native C++ value types, while the QSqlQuery is still available, and store that in your list to achieve your "caching".

[mmassaro]

@sierdzio technically you are correct, the exception comes from the list.at() call, but not because it goes out of bounds (AFAICS from the debugger). Both your gut feeling and @JonB intuition confirms what I was fearing, I just wanted to know if I missed something hidden in the docs.

I'll cache the field values themselves in the hope to avoid the issue altogether.

[sierdzio]

Unless you have some hardcore use case, perhaps you don't need to cache at all? SQLite is pretty fast, and Qt comes with QSqlQueryModel / TableModel helper classes. In my (limited :D) experience, it works really well and fast, even on slow hardware.