Don't use the QSettings class directly. This keeps the code more
consistent and makes it a bit easier to read. It also means that all
parts of the code profit from the settings cache that we have
implemented in the Settings class.
This should improve the detection of read-only query statements vs.
modifiying statements in the Execute SQL tab. The idea is to stop
looking for the SELECT keyword at the beginning of the statement and
instead fully rely on whether SQLite returns any data for this
statement.
See issue #1185.
Remove the valid flag from the SqliteTableModel class and remove its
usage in the Execute SQL tab of the main window. I believe this hasn't
been used for some time now because the main sources of error should
really be noticed before the query is even handed over to the model.
Additionally the valid flag wasn't as realible either anymore because of
the multi-threaded execution of the model queries.
The no collate function warning is triggered in a thread which is used
for loading data. However, the warning is a message box and GUI elements
can only be drawn in the main thread. So the old code would crash. This
is fixed here by jumping to the main thread for showing the message box.
In the SqliteTableModel class we need to know the total number of rows
in the table or returned by the query. This takes a considerable amount
of time and can be moved into a separate thread. I haven't done any
performance measurements with this but it might speed up switching
between large tables a bit.
There's no need to set sqlitebrowser as active window when updating
the main application window. The `activateWindow()` call prevents
switching workspaces in GNOME and Cinnamon desktops.
Fixes#934
When importing multiple CSV files at once, remove each entry from the
list of CSV files as its import completes. This way people can see the
list shrink visibly onscreen.
Also don't close the window if there are still files left to be
imported. This allows the user to import unchecked files, too, probably
using different settings.
See issue #1072.
With this commit the main window keeps track of the hidden columns and
re-hides them when the table is selected again. It also saves the hidden
status to the project file and restores it from there.
Instead of disabling the entire edit dock when the database is opened in
read only mode, only disable all buttons for making changes to the
field. This way the data can still be read using the edit dock.
See issue #1123.
In the Execute SQL tab, move the button for saving the results of a
query as either a CSV file or a view from the bottom of the results view
to the toolbar at the top.
See issue #1122.
Similar to commit 44eb2d4f99 this commit
makes use of the backend code improvements introduced in commit
532fcd3f6b.
It adds support for database schemata other than "main" to the Browse
Data tab. With this it's possible again to browse and edit data of
temporary tables using the Browse Data tab. This time, however, they are
separated logically from "main" tables. So handling temporary tables
should be a lot less error prone now, plus it's easier to tell for the
user what tables goes in what schema.
This commit changes the project file format. There is some code included
which allows loading of project files in the old format. However,
project files generated using versions after this commit can't be loaded
by older versions of DB4S.
Commit 532fcd3f6b added support for
multiple database schemata to the backend code. While doing this, it
removed support for showing temporary database objects in the user
interface.
This functionally is partially reimplemented by this commit. With this
commit temporary database objects are shown in the Database Structure
tab and in the Db Structure dock. Unlike before however, they are
visually separated from 'normal' database objects. Also this commit
tries to make use of the new schema handling code wherever possible to
also separate temporary objects programatically from the normal ones.
This wasn't done in earlier versions and effectively was a source of
all sorts of errors.
This commit still lacks support for temporary tables in the foreign key
editor and in the Browse Data tab. Also a substantial amount of testing
is still required.
This adds initial basic support for handling different database schemata
at once to the backend code. This is still far from working properly but
shouldn't break much either - mostly because it's not really used yet in
the user interface code.
The 'attach database' menu item was only activated after making changes
to the database and saving them. With this commit it's activated right
after opening a database, too.
In the Execute SQL tab we need to detect PRAGMA and VACUUM statements
before executing them in order to now execute them inside a transaction
which isn't supported by SQLite. If such a statement followed any other
statement however, the detection would fail, e.g.
pragma user_version=1; -- this works
pragma app_version=2; -- this fails
This should be fixed by this commit.
Some time ago we changed the Execute SQL tab to allow open SQL files
even if no database is loaded in order to provide an SQL editor without
needing a database.
If no database file is opened the Execute buttons were greyed out but
the F5/Ctrl+R shortcut would still work, causing an "out of memory"
error. That error doesn't cause any harm but is a bit confusing. So this
commit disables the keyboard shortcuts too.
This commit removes the File -> Remote menu entirely. The only menu item
that was left was the Save to Remote item which is replaces by a button
in the remote dock.
The button is only enabled when a database file is opened and the user
has logged in using a certificate.
Clicking the button opens the same dialog and performs the same actions
as before. The only difference is that we don't use the first client
certificate - no matter which one it is - but instead use the client
certificate that was used for logging in.
As per popular request, this adds support for setting PRAGMAs from the
Execute SQL tab. Since most PRAGMAs won't work inside a transaction we
make sure that we're not in one while the PRAGMA statement is executed.
If this means we need to commit any pending changes, the user get a
message box.
See issues #1021, #980, #966.
Allow opening new tabs, opening SQL files, and saving SQL files even
when no database is opened. Execution of SQL statements obviously is
still not allowed. But this should make it possible to use DB4S as a
simple SQL text editor if no better alternative is available on the
system.
Don't close SQL tabs when closing the databse.
When opening a database only close empty tabs, keep all non-empty tabs
opened. This should make sure that no SQL statements are accidentally
lost when opening a new database or simply closing the old one.
When opening a project file, close all tabs and load the new tabs from
the project file.
See issue #1035.
- Tweak input checker
- Preserve old file import as not to cause any unforeseen breaks
- Allow ignoring file name when importing multiple files to tables
- Mass toggle several files for import
Don't show the "Show rowid column" context menu item for views because
views don't really have a rowid column (it's always NULL). So showing
the column doesn't really make a lot of sense and might even confuse
some users.
Also change the order of the menu items a little to be more consistent
for views and tables.
This adds a new context menu option that allows unlocking views for
updating. This requires appropriate triggers to be in place and the user
to type in a column name that can be used as a 'primary key' for the
view. By default views are still locked from editing.
Inserting into and deleting from views isn't supported yet.
See issue #141.
When browsing a table and changing the sort order, then switching to
another table, and then switching back, we would sort the table twice:
once using the default sort order and then again using the previously
used sort order. This results in four instead of two queries for those
tables (including the COUNT queries). This commit fixes this so that
only two queries are executed which should cut the run time for these
cases in half.
See issue #1007.
This is to work around a Qt bug which is present in at least version
5.7.1. The problem is this: when you browse a table/view with n
colums, then switch to a table/view with less than n columns, you'll be
able to resize the first (hidden!) column by resizing the section to the
left of the first visible column. By doing so the table view gets messed
up. But even when not resizing the first hidden column, tab-ing through
the fields will stop at the not-so-much-hidden rowid column, too. All
this an be fixed by this line. I haven't managed to find another
workaround or way to fix this yet.
If anybody knows more about this issue please let me know.
