Add a new menu option to the Browse Data tab for changing the encoding
of all tables instead of just the one table.
Also check if the encoding the user typed in exists before trying to use
it to prevent a crash when an invalid encoding is used.
See issue #414.
When browsing and editing a table in the Browse Data tab allow the user
to change the assumed encoding of the text in the table. We'll then try
to convert from this encoding to Unicode for display purposes and to
convert from Unicode to this encoding for editing purposes. This way the
UI and all tools will keep using Unicode while the database format is
still respected. I hope the amount conversions generated this way won't
affect the performance too much.
See issue #414.
See issue #408.
This isn't working reliably yet on my system: If you enable the fix
restoring the previous settings when going back to a table doesn't work
and if you disable it that very way is the only way to change the
option. Don't know what's going on there :(
When opening a read only database file show a 'Read only' note in the
status bar of the main window and disable all editing buttons in the UI.
See issue #402.
See issue #383.
Also delete the custom styling sheets for the Data Browser tab in the
Preferences Dialog - no need to have these group boxes look differently
from all the others.
When generating SQL statements properly escape all identifiers, even
those containing backticks which apparently are allowed inside
identifiers in SQLite.
See issue #387.
This adds support for escaping backticks inside an identifier using
backticks as quote characters by adding a second backtick following the
first one (e.g. `test``test` => 'test`test').
When modifying a column e.g. renaming it there was a case where an error
message would be shown because of invalid SAVEPOINT handling. Try to fix
this issue by not creating a SAVEPOINT for creating a SAVEPOINT.
This should fix issue #390.
Change the success message for SELECT statement so that the amount of
time taken comes before the SQL statement itself because the time is a
new information whereas the statement is just a repitition for the user.
See issue #381.
Add a new option to the Preferences Dialog which activates horizontal
tiling between the SQL code editor and the result view in the Execute
SQL tab, i.e. the two widgets are shown side by side instead of one over
the other.
See issue #380.
There was a supposed to be a splitter between the SQL code editor widget
and the result table view widget in the SQL execution areas in the
Execute SQL tab. A splitter like this allows resizing the widgets around
it. Apparently this was broken some time ago (probably by me) and is
fixed by this commit.
See #380 which is partially fixed by this.
Fix the filters. For columns with a display format set they always
perform string comparisons but this is probably just something you have
to live with...
This is a proof-of-concept or even a basic first implementation of a new
feature I'd like to have in DB4S which at the moment I call display
formats.
The idea here is to allow the user to change the data in the Browse Data
tab on a per column basis before displaying it. This means even though
the data is stored in format X in the database it can be shown in format
Y in the browser. This should be useful in cases where the original
format X is hard to read or just not useful in a particular case.
This first implementation allows the user to right click on the header
of a column and open a new dialog for setting the display format which
offers a (limited) list of pre-defined formats. The selected format is
then integrated into the SELECT statement which is sent to SQLite.
While it works, this draft implementation lacks a number of features.
Here are the most prominent ones I'm currently aware of:
* Data not editable (or only via the Edit Dialog) because it isn't
transformed back yet.
* More display formats needed; maybe customizable ones, too.
* No indication in the UI for which columns a format has been set.
* Could _maybe_ be integrated into the import/export etc. for optional
use.
When changing the table in the Browse Data tab we used to remember the
column widths for that particular table. When changing the tab and then
coming back or when pressing the refresh button we used to save the
filters (but not for a table change). The sort order wasn't remembered
at all. I think this behaviour doesn't make any sense.
With this patch we remember column widths, sort order and filter values
for each table individually and restore it when the user switches back to
the table. All the settings are handled the same way and as much
information as possible is stored. It gets also saved in our project
file format.
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.
