Who is affected
You are affected by issue 31959 in case all of these 3 conditions are true:
- You run Openbravo on PostgreSQL.
- Your instance is (or was) in PR15Q4 or PR15Q4.1.
- You use (or used for some time while in these versions) Apache Commons DBCP Pool. This is, in the
externalPoolClassNameproperty is empty or not present at all. Note this is the default value for instances updated from previous versions, but not the default for new instances.
|When updating to any higher version (PR15Q4.2 or superior) the issue is not reproducible anymore.
But any data that might have been incorrectly generated will not be automatically fixed.
How it affects
This issue causes incorrect reads from database of date and date time values. It mainly affects Openbravo's data references, which has been detected to be read with one day of difference compared with its actual stored value.
This problem can, potentially, affect to any process/report using 2.50 (SQLC technology).
Below is the list of known affected processes but there might be cases that we did not manage to detect. If you think you have some area of the application that is affected, please contact Openbravo Support.
As reported in 31959, accounting process is highly affected by creating accounting records in a previous day that the one they should be in.
You can check whether there are incorrect records by running this script in database. Note after executing it, you should remove the created function by running
drop function getAcctDateMismatch();.
The output of this script is the number of records per table and client/organization with incorrect dates.
If there is any affected record, it is possible to recalculate the accounting by resetting it and re-scheduling the Accounting Process again.
The root cause is a bug in PostgreSQL JDBC library (version 9.4.1201 was included in Openbravo PR15Q4) affecting binary processing of date formats, see PR#387 and PR#376.
In Openbravo it affects processes and reports implemented with SQLC technology. It has not been possible to reproduce it for processes using DAL. It does not affect PL/SQL processes (functions nor triggers).