Return-Path: 
 <user-java-return-15206-apmail-ibatis-user-java-archive=ibatis.apache.org@ibatis.apache.org>
Delivered-To: apmail-ibatis-user-java-archive@www.apache.org
Received: (qmail 45450 invoked from network); 3 Sep 2008 17:51:58 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 3 Sep 2008 17:51:58 -0000
Received: (qmail 79239 invoked by uid 500); 3 Sep 2008 17:51:53 -0000
Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org
Received: (qmail 79219 invoked by uid 500); 3 Sep 2008 17:51:53 -0000
Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-java-help@ibatis.apache.org>
List-Unsubscribe: <mailto:user-java-unsubscribe@ibatis.apache.org>
List-Post: <mailto:user-java@ibatis.apache.org>
List-Id: <user-java.ibatis.apache.org>
Reply-To: user-java@ibatis.apache.org
Delivered-To: mailing list user-java@ibatis.apache.org
Received: (qmail 79208 invoked by uid 99); 3 Sep 2008 17:51:53 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2008 10:51:53 -0700
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_HELO_PASS,SPF_NEUTRAL,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [74.208.4.194] (HELO mout.perfora.net) (74.208.4.194)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2008 17:50:53 +0000
Received: from [10.54.218.190] (mobile-032-147-145-229.mycingular.net
 [32.147.145.229])
	by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis)
	id 0MKp8S-1KawVl06ai-0005QE; Wed, 03 Sep 2008 13:51:23 -0400
Message-Id: <38EFD8CF-76AE-4C6C-B88C-CF1A81F6A0A4@firm58.com>
From: Jason Kratz <jason.kratz@firm58.com>
To: "user-java@ibatis.apache.org" <user-java@ibatis.apache.org>
In-Reply-To: <19293940.post@talk.nabble.com>
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (5C1)
Mime-Version: 1.0 (iPhone Mail 5C1)
Subject: Re: Dealing with large CLOBs and Oracle 10g
Date: Wed, 3 Sep 2008 12:50:54 -0500
References: <19293940.post@talk.nabble.com>
X-Provags-ID: V01U2FsdGVkX1+UBjRej8J/mlcYtIUV99Zq1r12aNoRsrzBg6Z
 rCfiQHp/ERA1+nrJZc+6Y17GasGxjVrcmx1Vta6hqe+kauC+nE
 WEJ45MEynXmT7MBrSGof8Ke6Osy5Bm2
X-Virus-Checked: Checked by ClamAV on apache.org

Google it.  There is support in the 10g driver for this but requires  
some special setup.

Jason

Sent from my iPhone

On Sep 3, 2008, at 12:24 PM, Paul Sanders <tendancer@gmail.com> wrote:

>
> We recently upgraded our databases from 9i to 10g and now we are  
> running into
> a problem when fetching rows containing large CLOBs. Here's a  
> snippet of our
> resultMap:
>
> <resultMap class="Audit" id="fetch-audit-events-map">
>       <result property="oldData" columnIndex="12" jdbcType="CLOB"/>
>       <result property="newData" columnIndex="13" jdbcType="CLOB" />
> </resultMap>
>
> OLDDATA and NEWDATA are both defined as CLOB in the table.
>
> Queries that used to work before now fail with an Oracle error:
>
> org.springframework.jdbc.UncategorizedSQLException: SqlMapClient  
> operation;
> uncategorized SQLException for SQL []; SQL state [99999]; error code
> [22835]; --- The error occurred in
> com/sony/playstation/scert/mediuscentral/persistence/maps/ 
> AuditMap.xml. ---
> The error occurred while applying a parameter map. --- Check the
> search-audit-events. --- Check the output parameters (retrieval of  
> output
> parameters failed). --- Cause: java.sql.SQLException: ORA-22835:  
> Buffer too
> small for CLOB to CHAR or BLOB to RAW conversion (actual: 5548,  
> maximum:
> 4000) ; nested exception is
> com.ibatis.common.jdbc.exception.NestedSQLException: --- The error  
> occurred
> in com/sony/playstation/scert/mediuscentral/persistence/maps/ 
> AuditMap.xml.
> --- The error occurred while applying a parameter map. --- Check the
> search-audit-events. --- Check the output parameters (retrieval of  
> output
> parameters failed). --- Cause: java.sql.SQLException: ORA-22835:  
> Buffer too
> small for CLOB to CHAR or BLOB to RAW conversion (actual: 5548,  
> maximum:
> 4000)
>
> Some research reveals that in 9i a CLOB was truncated to 4000 chars  
> when
> converted to a string, but in 10g it now throws an Oracle exception.  
> Since
> it is iBatis that is doing the conversion I don't know how to start  
> going
> about fixing this - anyone got any ideas?
>
> Thanks
>
> Paul
>
> -- 
> View this message in context: http://www.nabble.com/Dealing-with-large-CLOBs-and-Oracle-10g-tp19293940p19293940.html
> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>