Also in version 4.3.0.4 Numeric values, when using the percentage field format are: - multiplied by 100 when converting existing standard number values in a table into percentages (they display for instance 2500% when the value was 25); - in a newly created table, any number is rounded to the nearest hundred (25 becomes 0%, 256 becomes 200%...); - the table won't accept 100 and 101 (constraint violation SYS_PK_169 - duplicate values) which is consistent with the previous remark.
1% = 0.01 . If you use a field without decimal places you can't save 0.01, only 1, 2, 3 → and that is 100%, 200% 300%. You have to declare decimal places for percentages, for example for 1%, 2% and so on 2 decimal places. If you will get decimal places in the percentages, you must define more decimal places in the table. 1.23% needs 4 decimal places, because the value saved in the database is 0.0123 . The value for a field shouldn't be changed by the format. So it is correct to make 2500% of the value 25. Can't confirm a bug here.
Don't mean to argue, bur if that's mathematically correct, it makes little sense: Calc uses figures, appends the percent sign (using the same menus and formatting options), and that's it! Shouldn't apps from the same suite be unified? It looks like a weird behavior, maybe not a bug, but then some kind of a writing convention that could probably be improved.
Anyways, this doesn't work for me. Creating a table with an Integer type field which gets a percent format keeps rounding numbers and the step between each value can't be less than 100. Do I miss something? The table will convert 125 into 100.00% and therefore won't accept any other value between 100 and 199...
(In reply to comment #2) > Don't mean to argue, bur if that's mathematically correct, it makes little > sense: Calc uses figures, appends the percent sign (using the same menus and > formatting options), and that's it! Shouldn't apps from the same suite be > unified? It looks like a weird behavior, maybe not a bug, but then some kind > of a writing convention that could probably be improved. Type in Calc in a cell 1. Set the format to percent: changes to 100%. Its the same behavior. Integer are values without decimal places. Databases are very strict with handling of the defined values. You have to use NUMERIC or DECIMAL to get values like 1.23. You have to define the number of decimal places before you could save it. Type in Calc in a cell 1.23 . Change the format to percent: changes to 123%. A bug is: Base offers the possibility to chose percent for a INTEGER field in the table-definition. Shouldn't be possible. But the value of 100% is indeed 1 and nothing else. So 1 is saved in a INTEGER field for 100% and 199%. Every input after the decimal point could never been saved. The title of this bug is misleading. So create a new bug for the possibility to chose percent for a INTEGER field, which couldn't be saved in it.
Sorry to say, but NO. I don't get the same behavior in Calc. I type 1, i get 1% I type 12, i get 12%.
You're right as of changing the formatting of en existing cell. It does what you say. But not if the number is written in a pre-formatted cell with percent format.
And the behavior is the same whatever is chosen for the field type (integer or not). Sorry, didn't mention that. But all types of numeric fields have been tested with the same result.
Created attachment 104834 [details] Open the table and have a look at the percentage-values. Don't know what you are doing. I have tested it with LO 4.1.*, 4.2.* and also 4.3.0.4. All the same result. Works as I have described: Two digits for the Decimal field, defined in the table, could save 1%, 2%, 3% and so on. Four digits for the Numeric field, defined in the table, could save 1,123% and other values. No problem here to get different percent-input in well formed fields. Only the Integer-field has the wrong format and has problems to show right percentage values, because there are no decimal places for this field-type.
My mistake! Apologies and thanks for the tip! I was using decimals from the field format window not from the table editor. Case closed i guess...
(In reply to comment #9) > My mistake! Apologies and thanks for the tip! I was using decimals from the > field format window not from the table editor. Case closed i guess... So I will close this bug as Resolved → Notabug. The possibility to set Integer-fields to percentage is misleading. Don't know if this could be fixed without great problems - but this would be another bug/enhancement request.