When opening a database fails a proper error message is now shown which
hopefully tells the user what the source of the problem is. Note: this
will only work for newer versions of SQLite.
This requires a bug fix which is included in this commit. The error
message wasn't taken from the correct database handle, so it had nothing
to do with the actual error source. This is fixed by this commit as
well.
This fixes two issues with unusual but valid data types for columns:
1) When having a data type that consists of more than one word these
wouldn't be separated anymore after parsing. This is fixed now. Example:
CREATE TABLE test(a long int);
would have become
CREATE TABLE test(a longint);
2) Some keywords are allowed to be used as data types. Parsing these
tables would have failed entire prior to this. This is fixed, too.
Example:
CREATE TABLE test(a no);
would fail.
This fixes tables like these where a keyword (in this case NO) is used
as an unquoted default value for a column:
CREATE TABLE test(a DEFAULT NO);
See issue #877.
This keeps the defaults in one place (the foreign keys defaults weren't
even the same in sqlitedb.cpp as in Settings.cpp!), makes the code a bit
easier to read, and makes use of the settings cache for better performance.
Renaming a table always happens *after* editing all table columns (at
least that's the order we're doing it currently). So for all
renameColumn() names we'll need to use the table name as it is in the
database, *not* as it is in the table name widget because that might
have been changed in the meantime.
Parse named primary keys correctly when they are in a column constraint,
not in a table constraint. E.g.
CREATE TABLE `a` (
`x` INTEGER CONSTRAINT c PRIMARY KEY, -- Name 'c' here
`y` INTEGER,
);
See issue #741.
Previously the grammar parser would fail to extract and store the name
of a foreign key constraint in statements like these:
CREATE TABLE test(
a int,
b int CONSTRAINT this REFERENCES xy(id) -- See the 'this' name
);
See issue #741.
Table definitions like these wouldn't work before:
CREATE TABLE test(
a int NOT NULL, -- This worked fine
b int NULL -- This didn't but does now.
);
See issue #741.
When our grammar parser doesn't fully understand a create table
statement yet, it'll set a flag to indicate the modifying this table
will result in errors: the nonunderstood parts will be removed from the
table while editing it.
The code for this feature, however, had a bug that was triggered by some
compilers (gcc in my case) because of an ambiguous function call. That
ambiguity and thus the resulting bug are fixed by this commit, making
sure the warning appears on all systems.
This was fun to debug...
This adds basic support for parsing CREATE VIRTUAL TABLE statements to
the grammar parser.
This doesn't mean that those tables are handled correctly at all.
Especially editing them and browsing them isn't working. But it didn't
work before this either.
See issue #917.
When editing a column of an existing table, this process might fail for
all sorts of reasons. Instead of printing an error message to stdout
this commit changes it to show a message box, so the user knows the
editing failed.
Adding a primary key to a table that didn't had a primary key before
would have added the column to the sqlb::Table::primaryKey::emptyFieldVector
variable (which is static!) instead of actually creating a new primary
key.
This way the primary key wouldn't be created as a new table constraint.
See issue #918.
Suppose you have this table:
CREATE TABLE `test` (
`a` INTEGER PRIMARY KEY AUTOINCREMENT,
`b` INTEGER
);
Editing this and removing the primary key would lead to this table
statement:
CREATE TABLE `test` (
`a` INTEGER,
`b` INTEGER,
PRIMARY KEY()
);
This is fixed by this commit, the invalid empty primary key line isn't
outputted anymore.
This adds a basic table of 12 colours which DB4S chooses from when new
plot graphs are added. This also introduces a pointer to this table of
colours which if moved forward each time a graph is added. This it's
less likely that two graphs have the same colour in one plot.
A better but more complex approach would be to find an algorithm to
generate new colours dynamicalls. See issue #816 for details.
