SQLiteStudio CRASH (bug)
Details
UPDATE: 20-02-01 3:48 ...after you read the original issue below, here is an added clue
- I knew it had happened to me a few days ago as well, but had disregarded it because I wanted to keep my mind on the issue at hand.
- in fact I can type any text in the SQL Editor window that will result in an empty screen and an error
- then right-click the empty window BOOOM! to the OS! lol
ORIGINAL ISSUE:
- clipped a cell's data in read mode or edit mode (Ctrl+C) from one table (content is a simple query)
- click on an SQL Editor window ... paste query, execute query - (blows up, returns a blank screen)
- I go fetch it again, paste it, ...SQLiteStudio BLOWS UP, POOF it goes, no longer in the Task Manager
- a simple right-click to access the context menu on that blank window also BLOWS SQLiteStudio off fthe screen (may or may not show the warning dialog that it encountered a problem)
- I know at least one cause I had renamed a database(Name in the list, NOT ON DISK) and the query points to the old name.
- corrected query, now ok - so code fails on a non-existing db in the list (bug)
- looking to not crash I sought to close the blank window
- Arhrhhhhhhhh I bring the windows list toolbar and cannot tell which button is current window ...after some pain I decide which button it is, and right-click it to close the window
- no crash and able to run the corrected query
NOW check out the Error in the STATUS window !?!?!? The DB selector (after having to go to a SQL Editor window to see it Grrrrrrrr!) happens to be set on the correct DB, and why the Error names it... if it was set to another DB... I would be misled that I am in the wrong DB, and go thru another CLONK moment until I could assess that this does not matter since I am qualifying the DB in the query! ERROR: Error while executing SQL query on database 'correctDBname': no such table: badDBname.correctTABLEname
Steps to reproduce - in Details
Operating system - WIN7 Pro
SQLiteStudio version - 3.2.1
Same on v 3.12.2 on Kali Linux. Crashes randomly after executing a new SQL command. It doesn't seem to be connected to a DB size or particular command being used.