I have a Table with monetary values set as "Floating Point" and this works OK. Some of these are naturally '0' (Zero) The '0' value shows up in the Table OK and in the Query OK. But in the Report only some show up - where they dont show up there is just a blank!! I tried setting the 'Value" to '0' and it made no difference. If you set this value before selecting the Data Source the '0' shows up correctly.
Can you attach an example?
I just tested this on the usda database, which has a table nut_data with several floating point fields. It worked fine, no blanks were shown where the values were 0. A small test case would be useful in this case. Thanks
Created attachment 105400 [details] Table design Table design: insert one field with floating point type, don't change the 'Default value' property
Created attachment 105401 [details] Data Enter data: 1, NULL 2, NULL 3, 1 4, 0
Created attachment 105402 [details] Report Create report based on the table. Two first records are NULL so the value is not displayed. Then there are two more records: a=1 and a=0.
Created attachment 105403 [details] Fix Apparent issue users may have is different then: by default the default value is 0.0. It is displayed as 0 in the table view while in fact the value gets not inserted and NULL. So initial default value is NULL. Two proper fixed for us would be (see this screenshot): - avoid displaying the blue "0" as default values in the table view and instead display nothing - fix display for inserted records when there's unset default value: don't display anything in such values of records Current workaround: To have the default value = 0.0, change it to 0 in the table designer for the field. It won't trigger data removal. If this won't work, change to 1 then to 0, and save the changes. Subsequent records that are inserted then will have the value of 0 inserted and the report will display them as 0.
Waiting for confirmation of the above description.
Should be fixed in 3.0.2 and later
Have tried this - All 6 Table fields are set as "Integer Number" All Fields in the Report are set with default value '0' NO CHANGE - No '0' values show in Queries or Report. Entering a '0' value in the Form - vanishes as soon as you press 'Save' Tested with 2.9.11 and last two AppImages.
Created attachment 105421 [details] attachment-15584-0.html Hi Jaroslaw On 05/09/2017 02:57 AM, Jarosław Staniek wrote: > https://bugs.kde.org/show_bug.cgi?id=379306 > > Jarosław Staniek <staniek@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > > --- Comment #7 from Jarosław Staniek <staniek@kde.org> --- > Waiting for confirmation of the above description. > Have just tested this and reported on the Bug Forum (NO CHANGE :-( ) _*NEW PROBLEMS*_*_(??)_ * As you know I have a Members Database and from this, with a Query, I select a Group of the Members. I then created a Report to print out or email a Report for each of these selected Members. *Problem 1* - I have >300 Members and the one Group is about 180 of these. I can not find a way to select a particular Member to bring up the Report for him??!! I CAN do it manually by clicking through ALL the records one-by-one until I find the one I want. Am I missing something - How can I do this?? *Problem 2* - Once I have the Report on screen that I want I select "Report > Export as > PDF" BUT it prints out the _FIRST_ Report not the one selected on-screen. Again am I missing something or doing it wrong?? If you confirm this I will post it. Thanks - (Been busy here with my monthly Journal - will get back into the Bugs next week)
Created attachment 105422 [details] FS Sig.png
Ian, correct. Integers have the same behavior that I explained above. Some or all of your fields have default values set to NULL even if you see 0 in the table designer. You can use workaround from https://bugs.kde.org/show_bug.cgi?id=379306#c6 to correct default values. But you would need to fix existing values for records you already entered.
@Ian please post the questions on the Forum because these are not related to this bug.
Created attachment 105557 [details] No Zero shows in Table and Query
Created attachment 105558 [details] No Zeros in Report
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I received the following from Ian: --- I notice the update to this bug that I reported some time ago. I am still a big user of Kexi and LOVE it. However I have had no way to update and monitor the Project - which I agreed to do with Jaraslaw. I use PClinuxOS-64bit with KDE and QT5 as my Operating System and it is not in the Repos of this OS. So I used to make use of the AppImage file to install it. But I understand that AppImages are no longer available. So I'm stuck with the version 3.1 Alpha of Kexi with which I run my two Databases!! I would love to be able to keep up with the new developments and make comments and suggestions but I'm unable to do that. So I'm unable to see if the above Bug has been fixed or is still present in the latest versions. It IS present - as I reported - in the version I use. --- Due to this, I'm going to mark this Reported.
Thanks Andrew and Ian. As you know 15 or 30 days is very small period. Many distributions refuse to update even in 2 years... Most users are unable to build the software themselves. Here I think we know a bit more and we analyzed the problem.