Remove all \r characters from a table defintion when reading it. This
makes sure it doesn't appear as a invalid character in the UI.
This commit improves the displaying of EoD's database from issue #63.
When importing a CSV file without no quote characters no spaces were
imported. So this...
a,b b,c
...would become...
a,bb,c
Fix this by not checking for being in quote mode when not having
configured a quote char anyway.
Get rid of the dependency to the MainWindow class in the DBBrowserDB
class. It was only used for calling the log SQL and set database state
functions anyway. The same result can be achieved emitting Qt slots.
Fixed a problem with the import of .csv-files
This fixes the import of CSV files with multi-byte UTF-8 characters in them. Also handle CSV files without a trailing line break better.
During the import, the parser used to append blanks between quotes and separators as part of the cell-content.
Now blanks are detected and ignored, iff they are not used as separator or in between quotes.
Previously, the read-line was performed using the stream-operator. Unfortunately, this approach limited the possible reading range to a word, causing problems when parsing files with blanks between the quotes and separators.
Instead, the readline is performed using the readLine() method of the QTextStream class.
Up until now, the DBBrowserDB:decodeCSV used to load the csv-file character by character using the getChar() method of the QFile-class.
Unfortunatelly, this approach caused multibyte-chars as used for UTF-8 encoding to be split and displayed incorrectly.
The fix uses the QTextStream-class to load the file line by line.
Every line is then again iterated character by character, before the old algorithm is applied. Using this approach, the characters are loaded and encoded properly. Splitting multibyte-chars is thus prevented.
When closing the database, either by using the menu item or by closing
the window, the user is asked whether the changes he made shall be
saved or not. Add a third button to this message box which makes it
possible to cancel the action.
Add two buttons to move the currently selected field up or down to allow
changing the field order of a table.
Extend the DBBrowserDB::renameColumn() method to support changing the
position of a field.
Delete the getTableSQL() method in DBBrowserDB. Because we reload and
store the SQL statements for tables after every change to the DB layout
we can just use these strings instead of having an extra function doing
an extra DB query. This simplifies the code a bit and also reduces the
number of SQL statements executed by the application.
Merge the renameColumn() and dropColumn() methods. They are just way too
long and complicated but also very similar that it makes no sense to
keep them separated.
This also simplifies the code of renameColumn() a bit while fixing the
trigger/view/index problem in dropColumn().
When reading in the DB layout use our SQL grammar parser to determine
the fields of a table. This simplifies the code a bit and might also
give more detailed information in some situations.
Save views, triggers and indices before deleting the old table in
renameColumn() and try to create them again after renaming the new
table. This is likely to fail and we'd probably need a grammar for these
objects to make the appropriate changes, so in case it does fail this
just prints a warning with some ideas of what to do.
Fix the updateSchemea() method to also read and save the not null flag
and the default value of each column.
This fixes a problem in renameColumn() which made it "forget" these
values. It is now possible to set the not null flag of multiple columns
in EditTableDialog.
Allow setting the default value, the check values and under some
circumstances the not null flag when editing existing tables.
This required some changes to DBBrowserDB::renameColumn() which is now
using some more features of sqlitetypes.cpp but could still be improved.
Remove the dirty flag as it is no longer needed. Because we track the
savepoints currently held open we can just use that list to see wether
there are changes to be committed. So there is no need to track this in
a separate variable.
Allow multiple savepoints in DBBrowserDB, i.e. setRestorePoint() doesn't
simply return if the DB is already set to dirty but creates an
additional savepoint.
Track the names of all savepoints which have not been either saved or
reverted yet.
Finally, and that's the whole point of this commit, change the savepoint
logic of the EditTableDialog. We used to have a transaction started when
opening a database which was only committed when the file was closed
again. This way the EditFileDialog could savely create a savepoint when
being opened and just release it when OK was clicked or revert to it
when cancel was clicked. Getting rid of the transaction broke this
logic. The dialog still worked but as the savepoint was released when
the changes were applied all changes made via the dialog were
immediately committed to the database. So clicking the revert button had
no effect on those changes. This is at best an unexpected behaviour but
could also be a problem when some changes are reverted while others
aren't. So, having the option now of keeping multiple savepoints opened
this problem can be fixed by just creating a new savepoint every time
the dialog is opened, reverting to it when it is cancelled and _not_
releasing it when OK is clicked.
I hope this works!
Add a new dialog which is shown when compacting the database. This
dialog allows selecting single objects individually to avoid vacuuming
the entire database.
It also shows a new warning if the database is dirty as changes are
going to be saved before vacuuming.
Create a restore point in executeSQL and executeMultiSQL instead of just
setting the dirty flag. This way the changes made using these functions
are not applied immediately when no restore point was created yet.
When creating a SQL dump of the database don't export the sqlite_stat1
table as it's impossible to import it later because SQLite generates it
automatically.
Remove some useless debug messages, e.g. because they just print an SQL
string which you can see in the SQL log window anyway.
Change some "critical" errors messages to just warning. No sense in
printing a critical error message when the program can handle the
problem by itself.
