They are kind of pointless because, really, they never should be visible
to the user. If there is no error we shouldn't show an error message and
if there is an error we should show a proper error message.
Especially during bunch executions of SQL statements by calling
DBBrowserDB::executeSQL() (like when importing a huge CSV file) this
avoids a whole bunch of string copy operations and calls to tr() and
should therefore increase the performance a bit, too.
This suddenly failed on my system and broke the CSV import. Maybe
because of some new version of some software? Either way, the new
version should work anywhere.
Add a tooltip to the database browser when you hover a cell with a
foreign key set in order to show the referenced table and column.
When clicking on such a cell while holding the Ctrl and Shift key (only
one of them won't work because they are for multiselection and Alt
doesn't do the trick on my system because it's just for grabbing and
moving the window) try to jump to the table and row which is referenced
in the clicked cell.
See issue #192.
When foreign keys are enabled it used to be impossible to change a
column of a table which is referenced in a foreign key. This is because
the table gets dropped in the process of renaming the column and only
then replaced by a new version.
With this commit the foreign keys are disabled for this short period of
time where the table doesn't exist and the old settings value is
restored as soon as the renaming is done.
See issue #362.
When opening a database we set the foreign key constraint checking
according to the preferences set in the Preferences Dialog. But when
creating a new database this wasn't done accordingly which means the
behaviour of the application is different depending on wether a database
was opened or newly created. This is changed by this commit.
In the EditTableDialog, when trying to edit a column which is referenced
in a foreign key of some other column (and thus cannot be changed
without errors ocurring during the rename process) print an error
message instead of just going on.
See issue #362.
This changes the SQL grammar parser so that it parses foreign key
clauses instead of just reading to the end of the clause when
encoutering one. This allows using the information inside the clause
later in a more effective way. However, as of now this isn't used yet.
This commit only attempts to imitate the old behaviour using the new
approach (and might fail doing so, causing new errors...).
