Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0001950 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [Openbravo ERP] 07. Sales management | minor | always | 2007-09-13 09:27 | 2008-06-12 09:43 | |||
Reporter | user71 | View Status | public | |||||
Assigned To | cromero | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | 2.35 | |||
Status | closed | Fix in branch | Fixed in SCM revision | |||||
Projection | none | ETA | none | Target Version | ||||
OS | Any | Database | Any | Java version | ||||
OS Version | Database version | Ant version | ||||||
Product Version | SCM revision | |||||||
Merge Request Status | ||||||||
Review Assigned To | ||||||||
OBNetwork customer | No | |||||||
Web browser | ||||||||
Modules | Core | |||||||
Support ticket | ||||||||
Regression level | ||||||||
Regression date | ||||||||
Regression introduced in release | ||||||||
Regression introduced by commit | ||||||||
Triggers an Emergency Pack | No | |||||||
Summary | 0001950: Invoice Customer Report returns nothing when dates specified | |||||||
Description | 2.33 running against Postgresql When you specify dates in the Invoice Customer Report it never returns any data. I think this is because the dates are passed in as strings as a parameter to the generated sql. My guess is that they are not converted to dates because the are specified as strings. Altering the sql & the servlet so that the dates are added to the sql string instead of being passed as parameters makes it work properly. (Not tested against oracle). Patch attached with fix | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
![]() |
|
![]() |
|
(0002101) user71 2007-09-14 03:09 edited on: 2008-06-12 09:21 |
Logged In: YES user_id=1737231 Originator: YES After looking at some other reports I think a cleaner solution is to add a to_date function around the date parameters. New patch follows File Added: invoice_customer_report.patch |
(0002102) user71 2007-09-18 09:12 edited on: 2008-06-12 09:21 |
Logged In: YES user_id=1737231 Originator: YES Environment OS: Linux - Centos 4 (test/prod) & Windows XP (dev) DB: Postgres 8.1.9 (test/prod) & 8.2.4 (dev) Release: 2.33 Browser: Firefox 2.0.0.6, IE 7 |
(0002103) cromero (viewer) 2007-10-17 13:12 edited on: 2008-06-12 09:21 |
Logged In: YES user_id=1500614 Originator: NO You are right. It is needed for postgre the explicit cast of the string in order to be able to compare with another date (Oracle makes an automatic cast). This bug has been fixed and will be published with the next release (r2.35). Thank you Carlos Romero Openbravo Team |
(0002104) user71 2007-10-25 22:00 edited on: 2008-06-12 09:21 |
Logged In: YES user_id=1338238 Originator: NO AT235: Tested in R2.35/Oracle - data is returned (report is displayed) IF dates are in correct format (dd-mm-yyyy). - It accepts dates with 2-digit year and no error message is issued BUT no data is returned (report displays blank). Tested in R2.34/Postgres - same behavior as above BUT reported bug no longer exists, i.e., dates are passed to Postgres and, as long as they're in valid format (dd-mm-yyyy), data is returned and the report is displayed. --- pleandro |
(0002105) cromero (viewer) 2007-11-06 19:03 edited on: 2008-06-12 09:21 |
Logged In: YES user_id=1500614 Originator: NO This bug has been closed. We have opened a new one (https://sourceforge.net/tracker/index.php?func=detail&aid=1823407&group_id=162271&atid=823129 [^]) to correct the different way in which Oracle and Postgre work with 2-Digit dates. Carlos Romero Openbravo Team |
(0002106) cromero (viewer) 2007-11-06 19:04 edited on: 2008-06-12 09:21 |
Logged In: YES user_id=1500614 Originator: NO Bug fixed. Carlos Romero Openbravo Team |
(0005539) user71 2005-06-01 00:00 edited on: 2008-06-12 09:43 |
This bug was originally reported in SourceForge bug tracker and then migrated to Mantis. You can see the original bug report in: https://sourceforge.net/support/tracker.php?aid=1793727 [^] |
Copyright © 2000 - 2009 MantisBT Group |