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.
When parsing a CSV file we used to check the column count for each row
and track the highest number of columns that we found. This information
then could be used to create an INSERT statement large enough for all
the data.
This column number tracking code is removed by this commit. Instead it
analyses the first 20 rows only. It does that while generating the field
list.
Performance-wise this should take a (very) little longer but makes it
easier to improve the performance in other ways later which should more
than compensate this commit.
Feature-wise this should fix some (technically invalid) corner-case CSV
files with fewer fields in the title row than in the other rows. It
should also break some other (technically invalid) corner-case CSV files
if they are imported into an existing table and have less columns than
the existing table in their first 20 rows but later on the exact same
number. Both cases, I think, don't matter too much.
Don't build a separate SQL statement per row to insert during CSV import
but use a single prepared statement which can be reused for each row.
This should speed up the CSV import noticeably.
When moving an existing table to a different schema which already
contains a table of that name, this causes an error. With this commit we
try to detect this type of error as early as possible.
This commit also updates the error message for that case. The old error
message still mentioned the 'temporary flag' which isn't correct
anymore.
Also, when changing the schema fails, reset the dropdown box back to a
working schema to avoid any confusion about whether the change worked or
not.
This replaces the checkbox for creating tables in the temporary schema
by a dropdown box that lets you select between all available schemata,
i.e. main, temp, and all attached databases. This way it becomes
possible to create new tables in attached databases as well as move
existing tables between all schemata.
This improves the Edit Table dialog to better handle moving tables from
one schema to another, though the UI currently only knows about the main
and the temp schema.
This also simplifies the grammar code by removing the temporary flag
from all classes because it's redundant now that we support multiple
schemata.
Commits 532fcd3f6b,
44eb2d4f99, and
ea1659e1d0 along with some smaller ones
prepared our code for properly handling schemata other than "main".
While working for any schema, they only exposed this funtionality for
the "temp" schema. But with these preparations in place it's easy to add
all known schemata to the UI and enable (almost) all features we have
for them. This is done by this commit, adding all attached databases to
the UI.
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.
This improves commit 44eb2d4f99 by
allowing to choose tables from other schemata than "main" in the foreign
key editor in the Edit Table dialog. This still isn't perfect as only
tables from the schema of the current table should be shown but with
some care it should work for all use cases.
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.
Remove the feature to select individual tables and indices to vacuum in
the vacuum dialog. Turns out SQLite doesn't support this (and apparently
never has). If you didn't select all tables at once, it would just print
errors to the console output. I have no idea why we ever implemented it
this way. However, the dialog could be reused to allow selection of
database schemata to compact - and this actually does work.
When closing a modified database a message box asking whether to save
the changes is popping up. The buttons were changed from Yes/No/Cancel
to Save/No/Cancel by commit 44361df4e9.
However, the code for this particular message box was still checking for
a Yes button click, and thus wasn't reacting on the Save button at all.
See issue #1117.
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.
Editing a table column in the Edit Table dialog accidentally committed
all prior changes to the database, effectively clicking the 'Write
Changes' button while working on the table. This is no problem if your
working on a clean database, but is a problem if you have made other
changes before. In the latter case you lose the ability to roll them
back and you can't use the Cancel button in the Edit Table dialog
anymore.
See issue #1116.
When changing an indexed column from a table using the Edit Table dialog
we try to update the corresponding indices as well. So if a column is
renamed all references to it in the indices are renamed accordingly.
This, however, didn't take into account that you can also remove
columns. While trying to update the column to nothing, the application
would crash. This is fixed by this commit. It doesn't crash anymore and
now removes the column from the index as expected.
See issue #1115.
If there is a local clone of a remote database but the remote database
has been updated to a newer version in the meantime, we're now asking
the user what to do. The choice is between downloading the newer version
and overwriting the local one with all the changes it might have
contained or opening the local version and not downloading anything.
See issue #1096.
Change the tab order in the encryption dialog so that the password
editor is the widget that is selected by default. That makes it possible
to type in the passphrase right away without navigating to the widget
first.
This fixes a regression introduced in d1e3e98006 which makes it
impossible to open encrypted databases with single quote characters in
their passphrase.
See issue #1105.
Oleg Prutz