Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Retrieving a stored QSqlResult throws an access violation error.
mmassaro last edited by
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
QSqlQuerylocal to the constructor of the model. My implementation of
data()then simply would retrieve the i-th element of that list via
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
QSqlQuerywith which I generated them goes out of scope?
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 last edited by JonB
Intuitively, but not based on any evidence, like @sierdzio I would say that a
QSqlRecordmust contain a reference to the
QSqlQueryit came from. If you look at all the methods you can call on a
QSqlRecordto 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
QSqlQuerygo 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
QSqlQueryis still available, and store that in your list to achieve your "caching".
mmassaro last edited by
@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.
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.