Summary: | EDITING: Table Design: changing column type does not reset length to default value | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Dan Lewis <elderdanlewis> |
Component: | Database | Assignee: | Lionel Elie Mamane <lionel> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | iplaw67, lionel |
Version: | 3.4.4 release | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Dan Lewis
2012-08-16 14:21:39 UTC
I can reproduce this behaviour on Linux Mint 64 bit with : LibreOffice 3.4.4 OOO340m1 (Build:402) Changing version to earliest version known to display buggy behaviour and confirming. @Lionel : assigning to you, if you have time to take a look, otherwise reassign to default. Alex And also reproducible in Version 3.6.0.4 (Build ID: 932b512) Alex Although I haven't tested, I'm assuming that if a user was not paying attention and saved the table as he/she had designed it with the buggy behaviour defaults, then any attempt to enter data subsequently, which was greater than the length of the assigned default length would truncate or fail ? Alex Yep, the following error message : SQL Status: 22001 Error code: -124 Value too long in statement [INSERT INTO "Table1" ( "active","ctry","top","txt") VALUES ( ?,?,?,?)] The final field "txt" was defined first as BOOLEAN, then I used the dropdown list to change it to VARCHAR and saved the table. Opened table in data entry mode, and started typing, using tab to switch between fields. The error message is produced when I try to tab out of the tuple and into the next new one. So at least there is some kind of warning for the user at the data entry level. Alex Oooh, this behaviour has just caused me to notice an unwanted side effect that IMO is a bug : Each failed insert causes the autoincrement index to update itself such that when the record is finally successfully written, the index with the latest increment gets written to the table. Failed inserts should not update the autoincrement counter. I'll file a separate issue for that. Alex I'm not 100% convinced that we should always reset the length to its (type-specific) default value. Not even sure we should *ever* do it. After all, the data that is already in these columns is type-converted, and the length specifier tells us how long it needs to be! For example: - change from VARCHAR to CHAR or vice-versa: these are similar datatypes, the length should be kept always. - change from FLOAT/NUMERIC/INTEGER to (VAR)CHAR: the number will be changed to a decimal representation, and the length specifier tells us the maximal length the result will have. I'm not sure I completely agree with you. However, this is a small issue since a person is suppose to know what length each field should be before creating the database. There is another another bug I plan to file this afternoon that needs much more attention than this does (LO 3.6.0.4 corrupts the Base database document file). |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.