Repository navigation
Crash in SqliteTableModel::getForeignKeyClause #942
Description
Details for the issue
- Open DB;
- Open 'Execute SQL' tab;
- Execute simply select query to retrive data;
- Hover mouse over cell 1:1 in retrieved data.
- Crash.
Useful extra information
For some reason SqliteTableModel::m_sTable is empty:
I'm opening this issue because:
- DB4S is crashing
- DB4S has a bug
- DB4S needs a feature
- DB4S has another problem
I'm using DB4S on:
- Windows: ( version: ___ )
- Linux: ( distro: ___ )
- Mac OS: ( version: ___ )
- Other: ___
I'm using DB4S version:
- 3.9.1
- 3.9.0
- Other: ___
I have also:
- Tried out the nightly version: https://github.com/sqlitebrowser/sqlitebrowser#windows
- Searched for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20
Activity
justinclift commentedon Jan 25, 2017
Awesome @schdub. @MKleusberg has been working on Foreign Key stuff recently, so this will probably interest him. 😄
vtronko commentedon Jan 25, 2017
Can't reproduce it.
Execute simply select query to retrive data;It's not enough, something tells me it's specific for your table/database.
Please, provide more useful information.
vtronko commentedon Jan 25, 2017
UPD: Sorry, I am able to reproduce it now. This happens if one hovers a cell for at least 3-4 seconds.
Working on it.
vtronko commentedon Jan 25, 2017
Tooltips in execute SQL tab can't be shown right now, since foreign key functionality relies on fixed size tables as static database objects.
I can only apply little fix that prevents crash right now.
Don't show foreign key tooltip within Execute SQL tab (#942)
justinclift commentedon Jan 25, 2017
Cool, sounds like progress in the right direction. 😄
MKleusberg commentedon Jan 27, 2017
Yeah, I don't there is much more that we can do right now. In order to support the foreign key tooltip + shortcut for queries in the Execute SQL tab we'd have to parse and understand SELECT statements and those can become quite complex. We'd need a mechanism to track which column in the results table comes from which column of which table in the database. It's the same effort that's needed to implement editing in the results view (see #393, and #141 as well).
justinclift commentedon Jan 27, 2017
@MKleusberg Should this be closed then?
It sounds like this is fixed, even though the solution isn't perfect for the long term.
MKleusberg commentedon Jan 27, 2017
Yeah, I guess we can close it. If you have the time you could open a meta issue for this instead to collect use cases for a full SELECT statement parser. This here is one of them, the two issues I've mentioned above are others, and maybe there are more.