Add a checkbox for setting the 'WITHOUT rowid' flag in the
EditTableDialog. All functionality concerning the checkbox is
implemented by this commit with one exception: Setting/unsetting the
flag on an existing table won't perform any changes yet.
See issue #51.
This commit allows you to add new rows to a table without rowid column.
The main problem here is that SQLite won't create the next value for the
primary key column itself, so we have to do that instead.
See issue #51.
This adds support for editing and deleting rows from tables without
rowid. It also fixes a check in the EditTableDialog when activating the
not null constraint as well as making some progress when it comes to
adding new rows.
Also see issue #51.
Keep all the table and field information in a sqlb::Table object (which
itself is stored in DBBrowserObject) rather than storing field
information in DBBrowserObject and sqlb::Table objects at the same time.
This doesn't really solve the problem, but reduces the chance
to have a nameclash with rowid, until we come up with something better
we can't fully support tables with a column name _rowid_ but that should
be very seldom
Change the window title of the toolbar to the same name it has in the
View menu as the window title actually is visible in the UI when right
clicking on the toolbar or menu.
When running a SQL statement the column widths of the result table view
are set to fit their contents automatically. However, for very long
values this makes the table hard to navigate. This is why this commit
introduces a maximum column width while still trying to fit each column
to its contents.
See issue #79, point 2.
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
* ??
All the editing in the EditTableDialog, that is the DBBrowserDB class to
be specific, messes up the current representation of the DB schema. This
is fine when the changes are actually committed by clicking the OK
button but causes confusion when the dialog is cancelled. None of the
changes are actually written to the database but the UI looks like they
are.
This closes issue #74.
