[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4635?page=c... ] Jonathan Tougas commented on HHH-4635: -------------------------------------- I ran into this problem and for the benefit of those who also run across this, here's are a few things I found while digging in a little. I am using hibernate-core 3.6.1-Final and ojdbc6 11.2.0.1.0. - This error occurs when there is more than 4000 bytes of data following a Lob bind variable. This means that you might run into this problem as soon as you have a lob and say a varchar2(4000) in the same table. - There isn't really a good way to dictate the order of the bind variables, but you can see the order that hibernate uses (see the tip in this section http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html_single/#que...). - A potential workaround is to put the lob in it's own table with a one to one mapping with the table you would have liked the lob to be in. This way the only data that may get inserted after the lob bind variable would be the primary key value. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4635?page=c... ] Strong Liu commented on HHH-4635: --------------------------------- would you please try the latest hibernate release? hibernate 3.6.5 or 4.0.0.beta3 hibernate 3.3 community release is not maintained anymore, or you can try move to jboss eap (http://www.jboss.com) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4635?page=c... ] Strong Liu commented on HHH-4635: --------------------------------- I didn't read this issue carefully (yet), here is the filter i just created which lists all lob related issues fixed in 3.6 and 4.0 https://hibernate.onjira.com/secure/IssueNavigator.jspa?mode=hide&req... but it would be good to try the latest release and see if the bug still exists -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4635?page=c... ] Strong Liu commented on HHH-4635: --------------------------------- okay, i tried org.hibernate.test.annotations.lob.LobTest with: {quote} @Column(length = 4000) public String getShortDescription() { return shortDescription; } {quote} and insert shortDescription a 4000 length data, but no failures (btw, i'm using master source which you can found at http://github.com/hibernate/hibernate-core, not 3.6 branch) so, would you please provide a test case? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4635?page=c... ] Reinier commented on HHH-4635: ------------------------------ Running into the same issue here... Situation: Hibernate version 3.6.0.Final and an Oracle 10 database (Character set: utf-8). One table with both a clob column and a varchar2(4000 char) column. Analysis: When I insert a string with a length of 4000 into the clob column and not the varchar column everything works fine. The other way around as well. When inserting data in both the varchar2 and the clob columns (2 strings with a length of 4000) the following error occurs: ORA-24816: Expanded non LONG bind data supplied after actual LONG or LOB column. And to make this behaviour even weirder, when I substring the value of the clob to a length of max. 1000 everything works fine as well.. Solution: By renaming the fields in the hibernate model so that the clob column has a name that comes later than the varchar2 column when ordering alphabetically (I prefixed the clob field in the java class with a 'z'), everything works fine because then the clob parameter comes after the varchar parameter in the query hibernate builds.. See http://ora-24816.ora-code.com/ So to summarize: ok: insert into table (clobfield, varcharfield, id) values (clob4000, null, 123) ok: insert into table (clobfield, varcharfield, id) values (null, string4000, 123) ok: insert into table (clobfield, varcharfield, id) values (clob1000, string4000, 123) not ok: insert into table (clobfield, varcharfield, id) values (clob4000, stringof4000, 123) ok: insert into table (varcharfield, clobfield, id) values (stringof4000, clob4000, 123) << create this situation by prefixing the field which represents the clob with a 'z') -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-4635?page=c... ] Jonathan Tougas commented on HHH-4635: -------------------------------------- Until a test case is submitted (I'm working on one, but I have little time) if you want to try to reproduce the problem the idea is to have hibernate create a insert statement where there is a lob column _followed_ by 4000 bytes of data. So for the entity above, if the insert statement is "insert into item (id, shortDescription, longDescription) values(?,?,?)", then no the problem will not occur. However depending on the order hibernate chooses, you can end up with an insert statement like "insert into item (longDescription,id, shortDescription) values(?,?,?)", and if the shortDescription parameter has 4000 characters, you should get the error. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HHH-4635?page=com.atlassian.jira.plug... ] Taro App commented on HHH-4635: ------------------------------- I have the same issue. I workaround the issue by using hibernate dynamic update functionality and asking users to update long text data fields one by one. That way, long CLOB and long VARCHAR2 columns are never updated at once. I'm lucky that the users do not complain so much. Just FYI, Oracle handles data potentially > 4000 bytes differently from data known to be <= 4000 bytes. The former is handled like LONG/CLOB, the latter is handled like VARCHAR2. Depending of database charset and client charset settings, number of characters safe to be <= 4000 bytes is different. For my Japanese environment with Oracle XE 11i (AL32UTF8 charset,) 1 character can be 6 bytes in AL32UTF8, so only 666 characters are safe. (666 * 6 = 3996, 667 * 6 = 4002.) So for me, ok : insert into (clobfield, varcharfield, id) values (str666, str666, 123); ok : insert into (clobfield, varcharfield, id) values (str667, str666, 123); ok : insert into (clobfield, varcharfield, id) values (str666, str667, 123); err: insert into (clobfield, varcharfield, id) values (str667, str667, 123); ok : insert into (varcharfield, clobfield, id) values (str666, str666, 123); ok : insert into (varcharfield, clobfield, id) values (str667, str666, 123); ok : insert into (varcharfield, clobfield, id) values (str666, str667, 123); ok : insert into (varcharfield, clobfield, id) values (str667, str667, 123); For other environments, maximum safe string length can be 1333 (1333 * 3 = 3999) or 1000 (1000 * 4 = 4000.) in any case, if long/clob/blob columns appear at last in insert/update statements, it should work fine. This issue is around from a long time ago (2007!): https://forum.hibernate.org/viewtopic.php?p=2396711 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira