I open this pull request, because there could be a better solution, which might imply refactoring in the signals emitted by the SqliteTableModel class.

Cool. This seems like it would have been super annoying to track down. 😄

Thanks, @mgrojo! As Justin says, this must have been awful to track down. I think this solution is the best for now. We could think about moving the if statement into SqliteTableModel::handleFinishedFetch() and don't emit the finishedFetch signal at all when only the row count is available and make use of the finishedRowCount signal for the Execute SQL code. But honestly I don't know if any other part of the code relies on these signals as they work now. So especially for a point release this is definitely better 😄

@mgrojo @MKleusberg Should this be merged into 3.12.1 as well?

Yes, good point! This bug was introduced in 1f9101a so it is present in 3.12.0.

Thanks, @mgrojo! As Justin says, this must have been awful to track down. I think this solution is the best for now. We could think about moving the if statement into SqliteTableModel::handleFinishedFetch() and don't emit the finishedFetch signal at all when only the row count is available and make use of the finishedRowCount signal for the Execute SQL code. But honestly I don't know if any other part of the code relies on these signals as they work now. So especially for a point release this is definitely better 😄

Thanks. I tried some changes in the connection or emission of signals (not sure about that specific case though), and they either gave other problems, or did not solve the issue). We should take a look again when we have to change something related to that code.

We should take a look again when we have to change something related to that code.

Yeah, I agree 👍