QSqlQueryModel::clear() crash when using multiple QSqlQueryModel on different tables

187 views Asked by At

In a PyQT5 project I use a QSqlQueryModel on a table 'A' to populate a ListView and a QSqlRelationalTableModel on same table mapped to some LineEdits. I also have a filter which calls QSqlQueryModel::clear(), QSqlQueryModel::setQuery(), QSqlRelationalTableModel::setFilter() and QSqlRelationalTableModel::select() to change the data in the ListView according to the filter. All this code is in a generic class which accepts some parameters to configure the models according to the table I need the model for. The graphic part is also included in a class. So the hierarchy is MainWindow has a TableAWidget which has a TableAModel which inherits GenericModel.

This works flawlessly if I use only one table and one widget.

If I add another table 'B' (identical to the first, only different name) and another widget which is an identical copy of the first only referencing the new table (so we have TableBWidget and TableBModel), the filter in TableBWidget works as expected but the filter in TableAWidget crashes on QSqlQueryModel::clear().

Some things to know:

  • in the widgets ALL members are coded as self.__variablename so there should be no 'static' members.
  • there are some variables which do not follow the self.__ style, but those are always local to functions.
  • the query string with the filter is always ok, and always different from TableAWidget and TableBWidget, so once again I don't see no 'static' things going around.
  • in the main window TableAWidget is showed before TableBWidget. If I switch the two the behaviour is also switched: TableAWidget's filter works and TableBWidget's filter crashes. So the order of display (which is also the order of inizialization and declaration) is what matters.

I don't really know what to do. I would like not to use only QSqlRelationalTableModel because I can't use it with ListView as I want to and the TableView looks awful.. Every suggestion is appreciated.

1

There are 1 answers

0
Delcaran On

The problem was a missing "static" variable. The connection to the database was an "instance" variable (prepended with self.) so the second instance dropped the connection that the first has already created, causing the first widget to crash when it tried to connect to the database.

Now I have moved the connection handler in the main class body and removed the 'self.' and everything works fine.