Fix parsing of table definitions like this one where there is a complex
check constraint using string literals:
CREATE TABLE "a" (
`b` TEXT CHECK(`b`='A' or `b`='B')
);
The grammar parser would fail to parse this statement correctly prior to
this fix.
See issue #179.
When entering a default value like "=(strftime('%s','now'))", don't
quote it but remove the '=' character and use the following expression
as default value.
See issue #166.
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.
When saving a SQL file in the Execute Query tab don't always ask for a
new file name but use the file name used when last saving the tab or
used when a file was opened. Add a 'Save As' menu option with the old
behaviour of always asking for a file name.
See issue #152.
Apparently after querying an encrypted database the handle is left in an
inconsistent state. So before setting any key or other encryption
details make sure to close and reopen the database to get a new, valid
handle.
Thanks to Nick (developernotes) and Stephen (sjlombardo) from the
SQLCipher forums for pointing this out!
Clear the result table view in the Execute SQL tab of the main window
when a PRAGMA statement was executed that didn't return any rows. Before
this, running e.g. 'PRAGMA table_info(test)' and then 'PRAGMA
table_info(tset)' would still present the result from the first query
even though the second should have cleared the view.
See issue #151.
Any SqlTextEdit object has its SQL syntax highlighter anyway, so it
makes sense to move the syntax highlighter object inside the text edit
class instead of maintining somewhere else. This hopefully makes the
code a bit easier to maintain.
Assuming you have a table names 't', the syntax highlighter would have
highlighted all ts in column names and other identifiers which aren't
highlighted otherwise. This is fixed by this commit.
When a field contains the separator character it need to be quoted as
well. On the other hand, checking for \r\n as well as \n is redundant,
so the former check can be removed.
See issue #144.
This fixes a bug which was introduced during the SQLCipher development
and which caused some settings loaded from a project file to be loaded
but then replaced by the default values which were loaded right
afterwards.
Add a new menu option to the main window (only visible when built with
the sqlcipher option enabled) which opens a dialog asking for new
encryption settings. These are then applied to a new database to which
all contents of the current one are exported. The old database is then
replaced by the new one.
This adds support for encrypting plaintext databases, decrypting
encrypted databases and changing the password or other settings of
encrypted databases.
If this turns out to work well enough we have functional SQLCipher
encryption support with only details missing.
Fix the sqlcipher build option in the qmake project to actually enable
the SQLCipher support.
Add a new dialog called CipherDialog which is used to ask the user for
the password and other encryption details instead of using standard Qt
input dialogs.
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.
When hovering over an item in the tree views of the Database Structure tab
or DB Schema pane, show a tooltip with the contents of that field.
See issue #139.