Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0031960Openbravo ERPA. Platformpublic2016-01-19 21:212016-01-21 08:42
egoitz 
caristu 
immediatecriticalalways
closedfixed 
5
3.0PR15Q4 
3.0PR16Q13.0PR16Q1 
alostale
Core
Production - QA Approved
2015-07-06
3.0PR15Q4
https://code.openbravo.com/erp/devel/pi/rev/70c0e8fd87ee [^]
No
0031960: Incorrect posting data when not defining an external connection pool on the Openbravo.properties
Having on the Openbravo.properties file the parameter without value the documents are posted on the previous date than the accounting date.

The configuration is:


externalPoolClassName=
The problem happens by default when updating to PR15Q4.

It is reproducible as:

Edit the Openbravo.properties file by replacing


externalPoolClassName=org.openbravo.apachejdbcconnectionpool.JdbcExternalConnectionPool

with

externalPoolClassName=

Then compile with
ant smartbuild
and restart tomcat.
Then access to the application.

Reset accounting for invoices
Schedule the accoounting background process.

When it finishes check the invoices and see that the accounting date of the fact_acct entries is one day before the accounting date of the documents.

REstoring the Openbravo.properties file solves the problem.
No tags attached.
blocks defect 0031959 closed caristu Incorrect posting data when not defining an external connection pool on the Openbravo.properties 
Issue History
2016-01-20 09:09alostaleTypedefect => backport
2016-01-20 09:09alostaleTarget Version => 3.0PR16Q1
2016-01-20 19:29hgbotCheckin
2016-01-20 19:29hgbotNote Added: 0083471
2016-01-20 19:29hgbotStatusscheduled => resolved
2016-01-20 19:29hgbotResolutionopen => fixed
2016-01-20 19:29hgbotFixed in SCM revision => http://code.openbravo.com/erp/backports/3.0PR16Q1/rev/94298e81b1533e3cea6b5c94e53fb09c97a72991 [^]
2016-01-20 19:33caristuIssue Monitored: alostale
2016-01-20 19:33caristuReview Assigned To => alostale
2016-01-21 08:19alostaleRegression introduced by commithttps://code.openbravo.com/erp/devel/pi/rev/30caa81f847ba1075d2b6e716fb1e4e8158dafe7 [^] => https://code.openbravo.com/erp/devel/pi/rev/70c0e8fd87ee [^]
2016-01-21 08:41alostaleNote Added: 0083485
2016-01-21 08:41alostaleStatusresolved => closed
2016-01-21 08:41alostaleFixed in Version => 3.0PR16Q1
2016-01-21 08:42alostaleNote Added: 0083486

Notes
(0083471)
hgbot   
2016-01-20 19:29   
Repository: erp/backports/3.0PR16Q1
Changeset: 94298e81b1533e3cea6b5c94e53fb09c97a72991
Author: Carlos Aristu <carlos.aristu <at> openbravo.com>
Date: Wed Jan 20 19:02:18 2016 +0100
URL: http://code.openbravo.com/erp/backports/3.0PR16Q1/rev/94298e81b1533e3cea6b5c94e53fb09c97a72991 [^]

fixes issue 31960: Incorrect posting data using postgresql jdbc connection pool


There was a problem in the binary transfer of Dates performed by the postgresql library version 9.4-1201. This problem is not happening on version 9.4-1207 because when the queries are executed it now includes a mechanism to identify if the fields of the query need to update their format to binary.

For this reason, to fix the problem the postgresql jdbc driver has been upgraded to version 9.4-1207

---
M build.xml
M legal/Licensing.txt
A lib/runtime/postgresql-9.4.1207.jre6.jar
R lib/runtime/postgresql-9.4-1201.jdbc4.jar
---
(0083485)
alostale   
2016-01-21 08:41   
Code reviewed

Tested accounting process using Commons DBCP and Tomcat pool, in both cases there are not mismatches in accounting dates.
(0083486)
alostale   
2016-01-21 08:42   
This issue affects PostgreSQL instances using Apache Commons DBCP Pool, this is externalPoolClassName property in Openbravo.properties is empty, which is the default values for instances updating to >=PR15Q4 from a previous version. Note that even this value is changed to use Tomcat Pool, if the instance was executing old value for a time, data generated in this period might be affected.

It affects accounting process. But it can also affect ANY other process implemented in XSQL (or using direct JDBC connections) doing operations on date fields read from database. It DOES NOT affect processes using DAL nor PL/SQL processes.

It is caused by issues 376 [1] and 387 [2] in PostgreSQL JDB.

[1] https://github.com/pgjdbc/pgjdbc/pull/376 [^]
[2] https://github.com/pgjdbc/pgjdbc/pull/387 [^]