Openbravo Issue Tracking System - Openbravo ERP | |||||
View Issue Details | |||||
ID | Project | Category | View Status | Date Submitted | Last Update |
0018517 | Openbravo ERP | A. Platform | public | 2011-09-13 10:10 | 2011-10-12 01:58 |
Reporter | mtaal | ||||
Assigned To | mtaal | ||||
Priority | normal | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Platform | OS | 5 | OS Version | ||
Product Version | |||||
Target Version | 3.0MP4 | Fixed in Version | |||
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 | 0018517: CLOB fields fails on oracle in the grid | ||||
Description | See this description: http://wiki.openbravo.com/wiki/Common_Issues_Tips_and_Tricks#Grids_with_CLOB_fields_fail_on_Oracle [^] | ||||
Steps To Reproduce | Research why not showing in the grid actually makes a difference, it should not. Find a solution in the query generator used in the ui, see the following remarks from an email exchange with Asier: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is an old known issue [1]. The problem is Oracle raises ORA-00932: inconsistent datatypes: expected - got CLOB when comparing (equals) a CLOB with a (var)char. So this query fails: select * from ad_preference where value = 'N'; whereas these other ones work: select * from ad_preference where value like 'N'; select * from ad_preference where to_char(value) = 'N'; In case you can do a hql instead of using a OBCriteria you can just add a to_char or replace = with like and you are happy. I guess the problem is we don't define in AD which is the actual DB column type, so DAL Criteria cannot do a different query for CLOBs and I don't know how would affect performance (but my guess is that not very good) changing all = with like or to_char. We might do it in the catch in case the criteria query fails... Or we might put a flag when generating the class (just for Oracle?) reading from DB catalog to treat this case differently. | ||||
Proposed Solution | |||||
Additional Information | |||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files | |||||
Issue History | |||||
Date Modified | Username | Field | Change | ||
2011-09-13 10:10 | mtaal | New Issue | |||
2011-09-13 10:10 | mtaal | Assigned To | => mtaal | ||
2011-09-13 10:10 | mtaal | Modules | => Core | ||
2011-09-13 10:10 | mtaal | OBNetwork customer | => No | ||
2011-09-13 11:37 | hgbot | Checkin | |||
2011-09-13 11:37 | hgbot | Note Added: 0040926 | |||
2011-09-13 11:37 | hgbot | Status | new => resolved | ||
2011-09-13 11:37 | hgbot | Resolution | open => fixed | ||
2011-09-13 11:37 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/devel/pi/rev/ac37116c4cc26350303c76dec7e0ac76f217b484 [^] | ||
2011-10-03 11:29 | marvintm | Status | resolved => closed | ||
2011-10-12 01:58 | hudsonbot | Checkin | |||
2011-10-12 01:58 | hudsonbot | Note Added: 0041661 |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|