Can you check that :

1) you don't reproduce on Demo version ( http://demo.projeqtor.org)
(to be sure it is a server side issue)

2) in database format for column work of table work is decimal(8,5)

3) in /model/NumberFormatter.php, you have : const DECIMAL=2;

4) check value for "number of hours per day" in Global parameters screen (should not be zero)

Hi babynus,

So as requested I checked the following points and confirm that:

1) I couldn't reproduce the problem on the online demo version, so it seems it is a server side issue
2) in database the type of column work of table work is: decimal(8,5) unsigned
3) I didn't find file /model/NumberFormatter.php but I think you meant /model/NumberFormatter52.php: const DECIMAL=2;^M
4) "number of hours per day" = 8

So all seems to be OK...

Have you other points to check maybe more related to the server config ? Here are some more data on my server config:
OS: CentOS Linux 6.5
PHP: Version 5.4.30
MySQL: version 5.5.38

Thank you for your support

Hello Michel,

just to chip in: we work with hours. This eliminates the issue in discussion and is more accurate in reporting the efforts.

Regards,

Klaus

To Klaus,

Thanks for trying to help. I tried to use hours instead of days but that didn't help. I think I read somewhere that allocations are stored in days internally...

To Babynus,

It was as you said a server configuration issue.

First it seemed to me that it was a PHP issue because when I updated PHP from 5.4.30 to 5.4.32 on my dev server it began to work. I found that #67052 was solved in 5.4.31. That bug is related to NumberFormatter and the LC_NUMERIC locale, that's to say the use of commas for float number.

But I still had incorrect registration in the database (table work, column work) on my prod server, as compared with my dev server where it was working right. Another issue was that sometimes, the display was empty !

I've finally found that it was a problem of locale: LC_NUMERIC was set to en_DK.UTF-8 on my prod server whereas it was set to C on my dev server. When the query to update the database was built, the value to update was converted from float to string and the decimal point was replaced by a comma on my prod server, which made the query fail because whatever the locale mysql expects a point for foating point values.

After investigation, I traced the source of the problem to a conflict between TRAC and ProjeQtOr which are sharing the Apache server. TRAC was setting the locale to en_DK.UTF-8 BUT that setting was impacting not only the TRAC thread but also the whole Apache process and therefore ProjeQtOr also, as stated in setlocale:

Warning

The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale().

So to put things right I reestablished Apache defaut locale setting (C) by removing Apache SetEnv trac.locale "en_DK.UTF-8 directive and defining instead TRAC date format through a specific TRAC configuration setting (default_date_format = iso8601).

Regards,

Michel