Actually handle the case that deleting rows might fail in the
SqliteTableModel. That's where this sort of check belongs.
This allows us to get rid of the full refresh of the table view after
deleting a row in the Browse Data tab. Thanks to @innermous for pointing
this out!
When not getting any data from query we'd tell Qt that we're about to
insert data anyway and cause confusion this way. At least this might
cause some trouble on some systems.
This issue tries to deal with issue #565.
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.
When generating SQL statements properly escape all identifiers, even
those containing backticks which apparently are allowed inside
identifiers in SQLite.
See issue #387.
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.
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.
Add support for non-integer primary keys, especially on table without
rowid column. The previous code often assumed that the rowid column or
its equivalent was a 64bit integer but SQLite allows any data, including
text, to be stored in there.
See issue #240.
In the edit dialog the clear button sets the data to
NULL, but because we check if the data has changed
before updating, we need to also check the NULL flag,
otherwise we can't tell NULL values from empty values.
See issue #220.
When replacing placeholders, QString::arg() looks for
the sequence %n (where n is a number between 1 and 99).
As it turns out this sequence can also appear in SQL
queries and so they were being mistakenly replaced.
See issue #203.
This improves commit c20c58595a to
definitely make sure the primary key values are stored and handled
correctly by simply using the same data type as SQLite itself does.
Apparently SQLite supports empty table names for whatever reason. This
commit patches SQLiteBrowser to support databases with a table with an
empty name. I haven't removed the check for an empty table name in the
Create/Edit table dialog though because you probably really shouldn't
create such a table.
See issue #194.
Primary keys in SQLite are 64bit in size. We, however, used the int
datatype which often is 32bit only. Also the conversion from QString and
other Qt datatypes to numbers was done by the toInt() method which fails
on these large numbers. These issues are fixed by this commit, adding
support for databases with big primary key values.
See issue #172.
Show 'NULL' for those fields in a table which contain a NULL value. This
allows the user to see the difference between an empty string field and
a NULL field.
Also change the format of the 'BLOB' information shown for binary data
to match the new 'NULL' information.
See issue #163.
Add some basic initial support for SQLCipher. Note that this is more of
a POC than a final implementation.
This commit adds an option called 'sqlcipher' to the cmake and qmake
projects which - when enabled - replaces the default SQLite3 include and
library files by their SQLCipher counter-parts. Especially on MacOS X
there might be some more work required in finding the correct include
paths. The SQLCipher library supports unencrypted databases, too, so
even if the option is enabled the program behaves like before. You can
see the difference, though, in the About Dialog where the SQLite version
string will say 'SQLCipher version xy'.
When the sqlcipher option is enabled and you try to open a file which is
neither a project file nor a normal SQLite3 database it is assumed now
that the file is an encypted database. There is no way to tell between
an invalid file and an encypted file, so in both cases a password dialog
pops up. When the correct password and page size are entered the file is
opened and can be edited like any other database before.
Creating encrypted databases isn't supported yet. So for testing you
need to fall back to the sqlcipher command line tool.
See issue #12.
This flag should indicate if we can fully handle this table definition
in our edit table dialog. if not we should do one of these things:
* disable the edit table dialog to modify the table
* display a warning message that modifying this table may remove constraints
* ??
