Not sure if this is the right place, but I couldn't find any other places to report a bug.

I've just started trialling Kexi because it seems to have a few features Base doesn't. I intially installed whatever version comes from the Ubuntu 13.10 software center, but it wouldn't let me create tables at all. I managed to find a PPA which upgraded it to 2.8.1 and I successfully imported all my data from my Base database, but I've run into a new issue: If I make even a minor change to a table's design, it erases all existing data in the table. I can get around this by exporting the data before the alteration, then reimporting it, but I'm sure it's not supposed to be like that.

Any suggestions?

Essence of Orange wrote:Not sure if this is the right place, but I couldn't find any other places to report a bug.

Hi, welcome in Kexi forum!
You can discuss issues here and report wishes and bugs at http://bugs.kde.org. (I just moved your topic to Kexi Help subforum from Discussions).

Essence of Orange wrote:I've just started trialling Kexi because it seems to have a few features Base doesn't. I intially installed whatever version comes from the Ubuntu 13.10 software center, but it wouldn't let me create tables at all. I managed to find a PPA which upgraded it to 2.8.1 and I successfully imported all my data from my Base database,

The default Kexi version was probably older than 2.7.3 so it contained this bug which made it impossible to use the Table Designer. Upgrading to 2.8.x fixes this indeed.

Essence of Orange wrote:but I've run into a new issue: If I make even a minor change to a table's design, it erases all existing data in the table. I can get around this by exporting the data before the alteration, then reimporting it, but I'm sure it's not supposed to be like that.

Rumors say this is a feature

Seriously, there is exactly 8 years old wish filed at bugs.kde.org. Its development started already but it's so costly, that I am still collecting resources to sponsor this improvement.

Thankyou for your prompt reply. Wow, 8 years? That's a bit unfortunate, hope it gets fixed soon. Base was similarly unpredictable, which is one of the reasons I switched.

In contrast, it can be predicted how Kexi behaves in the Table Designer: if you add/remove a field or change type, name, etc., it will ask you for permission to re-create the table and the data will be removed. But if you change secondary property such as Default Value, that does not alter the database physically (yes, that's complex term), then Kexi won't remove the data upon saving the design.

Actually, I found that if I alter secondary charactaristics (like "required" or "unique") it similarly erases all data upon saving the new design.

It's not quite as bad as base, in that you can rearrange the fields without corrupting the entire design, and you can at least reimport data if you save it first, but it's still a little unexpected for a newcomer.

I see how you may understand the 'secondary' aspect. A side note (that users don't have to care about, I admit): "required" or "unique" are properties of the database (backend: either MySQL, SQLite or PostgreSQL) and thus are primary 'physical' properties. This is a rule of consistency, especially in multiuser environments. Even if for Kexi+SQLite multiuser scenario isn't available.

I understand the issue of 'unexpectedness' for users that do not read the question dialog "Saving changes for existing table design is now required. Do you want to save the design now? Warning! Any data in this table will be removed upon design's saving!" too carefully. Before the ultimate solution™ arrives (the complete ALTER Table), would you mind to suggest solutions that improve user experience in the discussed aspect?

Some idea: reverting the altered design (and data removal) would be an option. We're quite close to have a "backup" feature for objects in Kexi, so based on this one reverting would be possible too.

Just going by the conventions I've seen in any other programs I've used, I'd say it makes good sense to separate save dialogues ("Are you sure you want to continue") from critical warning dialogues ("Warning, this will erase all your work"). The convention I've seen in other places is to announce the warning when the user tries to change a setting which will/may result in a data loss, but as that seems to be every setting right now maybe that's not so applicable.

As you said, the real solution is to allow the design to be altered without dropping all the data. Sure, some data might get dropped (with warnings) such as if a user tries to change the datatype from text to integers but I don't see why the entire table has to be erased just to make a particular field no longer a required entry for each record.

Essence of Orange wrote:Just going by the conventions I've seen in any other programs I've used, I'd say it makes good sense to separate save dialogues ("Are you sure you want to continue") from critical warning dialogues ("Warning, this will erase all your work"). The convention I've seen in other places is to announce the warning when the user tries to change a setting which will/may result in a data loss, but as that seems to be every setting right now maybe that's not so applicable.

It's good idea.. and you know what, how about going the non-intrusive path and using the message widget already known from KDE apps?

Like this orange box: http://kate-editor.org/wp-content/uploa ... covery.png

We could display it as soon as the user performs first action that will lead to the data removal upon saving.

What's more, in certain scenarios if the user clicks Save right after such an action, for example after removing/adding a column, it's possible to alter the table design without data loss. So extension of the idea would be displaying a hint like "If you *save* the design now, data will not be removed." I know, somehow confusing and forces users to act in a dramatically different fashion than they act with spreadsheets...
(anyway, less confusing and tiresome than copying/importing data back by hand)

How would this work for you?

Essence of Orange wrote:As you said, the real solution is to allow the design to be altered without dropping all the data. Sure, some data might get dropped (with warnings) such as if a user tries to change the datatype from text to integers but I don't see why the entire table has to be erased just to make a particular field no longer a required entry for each record.

The secret of complexity in the ultimate implementation (drafted at http://community.kde.org/Kexi/Plugins/T ... lter_table) is that user can remove any fields, add any fields, move some other, rename some other, and change the type, etc. Then press Save. We need to act atomically upon saving, and we cannot apply changes as soon as user makes them, otherwise for example changing from text to integer and back to text will clean up the data in general case.

The ultimate solution most likely will be interactive too, i.e. we're going to ask what to do when deep and risky conversion of data types is needed, e.g. from text type to date or integer.

Oh hey, thanks for the tip, I'll try that out next time I'm using it.

Sounds fantastic I look forward to it.