Sat, 06 Jun 2015 14:51:26 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Sat, 06 Jun 2015 14:51:26 +0000] rev 26865
CI: merge back from main

Sat, 06 Jun 2015 14:35:27 +0000CI: update AD_MODULE to version 26863
RM packaging bot <staff.rm@openbravo.com> [Sat, 06 Jun 2015 14:35:27 +0000] rev 26864
CI: update AD_MODULE to version 26863

Fri, 05 Jun 2015 23:09:57 +0200Related to issue Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Fri, 05 Jun 2015 23:09:57 +0200] rev 26863
Related to issue Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Close the scrollable result

Fri, 05 Jun 2015 11:07:14 +0200Related to issue Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Fri, 05 Jun 2015 11:07:14 +0200] rev 26862
Related to issue Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Changed warn to debug, can be set back to warn when subclass implementation has been improved

Fri, 05 Jun 2015 09:04:54 +0200Related to issue Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Martin Taal <martin.taal@openbravo.com> [Fri, 05 Jun 2015 09:04:54 +0200] rev 26861
Related to issue Related to issue 29766: Retail Operations Buffer: store all transactions in operations table before processing
Only read all non-clob columns from c_import_entry to prevent oracle driver reserving large memory chunks. Still read all other
properties as they can be used by derived classes to decide to handle or not to handle a specific import entry.

Thu, 04 Jun 2015 23:31:13 +0000CI: merge back from main
RM packaging bot <staff.rm@openbravo.com> [Thu, 04 Jun 2015 23:31:13 +0000] rev 26860
CI: merge back from main

Thu, 04 Jun 2015 23:15:24 +0000CI: update AD_MODULE to version 26854
RM packaging bot <staff.rm@openbravo.com> [Thu, 04 Jun 2015 23:15:24 +0000] rev 26859
CI: update AD_MODULE to version 26854

Tue, 02 Jun 2015 09:12:55 +0200Fixes bug 29708, Fixes bug 29936: Improve performance and memory problems
Unai Martirena <unai.martirena@openbravo.com> [Tue, 02 Jun 2015 09:12:55 +0200] rev 26858
Fixes bug 29708, Fixes bug 29936: Improve performance and memory problems

2 Problems are happening in Costing Background process:

1) Java Heap error: This problem happens because getTransactions method can load on memory a lot of objects and even an ScrollableResult is being used the following sentence 'OBDal.getInstance().getConnection().setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT)' prevents in fact to scroll properly the ScrollableResult. To avoid this issue the query of getTransactions method has been changed to return only 1000 records. So, instead of calling just once this method it is done once each 1000 records.

Also instead of returning a list of 1000 MaterialTransaction objects, that can be a relatively big amount of objects to load in memory, only the Ids are returned and each id the it is instanced on each iteration.

2) Performance problems: The process has a performance issue because it does a commit on each iteration of the list. Now, this has been changed to do commit every 1000 records, and in case that an exception is raised on a certain iteration a new method has been added in catch clause to calculate the cost of the transactions that have been rolledback but which there were properly calculated.

Thu, 04 Jun 2015 17:02:09 +0200Related to issue 30037: updated copyright
Víctor Martínez Romanos <victor.martinez@openbravo.com> [Thu, 04 Jun 2015 17:02:09 +0200] rev 26857
Related to issue 30037: updated copyright

Tue, 02 Jun 2015 09:06:32 +0200Fixed issue 30037: Completed quantity in the Work Requirement is not updated
Jorge Garcia <jorge.garcia@openbravo.com> [Tue, 02 Jun 2015 09:06:32 +0200] rev 26856
Fixed issue 30037: Completed quantity in the Work Requirement is not updated

Completed quantity in the Work Requirement is not updated under some
circumstances.

The problem was that the ma_workeffort_validate wasn't updated the UPDATED
column of the ma_wrpahse table and you can save even if the line had changed in
the work effort window.

The solution is to update the column with the actual date. Now, when you try to
save it, a error appears in the grid and the save is canceled.