From oracle-l-bounce@freelists.org Thu Aug 4 13:30:03 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j74ITwSs031717 for ; Thu, 4 Aug 2005 13:29:58 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j74ITqIP031691 for ; Thu, 4 Aug 2005 13:29:53 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 12D0D1DD006; Thu, 4 Aug 2005 13:29:46 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00582-01; Thu, 4 Aug 2005 13:29:46 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 873D51DCF94; Thu, 4 Aug 2005 13:29:45 -0500 (EST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YVbJYY2L/QpESguPw2aAQ+D/Dk81I3NUxkWHOAZoe4AXFjdK3GZeCVNlmPIjjjUIr8Zs8Q0SZu8mxwCh4Sc56GxLPq8eia24Opzt8lFSw3Oxp4ZA8opnrA4NDS5lmyT+hzHGDfaHb0T/nhgEAGdbGsSCe6fH9i1homOB6Xqdypk= Message-ID: Date: Thu, 4 Aug 2005 21:26:48 +0300 From: Edgar Chupit To: jkstill@gmail.com Subject: Re: 10046/10079 Tracing understanding - SOLVED Cc: mark.powell@eds.com, Oracle-L@freelists.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by Ecartis Content-Disposition: inline References: <5A14AF34CFF8AD44A44891F7C9FF41050395BA0A@usahm236.amer.corp.eds.com> X-archive-position: 23421 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: chupit@gmail.com Precedence: normal Reply-To: chupit@gmail.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-mailscan-MailScanner-Information: Please contact the ISP for more information X-mailscan-MailScanner: Found to be clean X-MailScanner-From: oracle-l-bounce@freelists.org X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Jared, But now think about this from the driver perspective, when you call this procedure from java you simply define type of the second parameter and that it is output parameter, without specifying expected length of the data. I.e. you call stmt.registerOutParameter(3,Types.VARCHAR); Oracle JDBC driver has no idea about what will be the maximal length of the output parameter, so it reserves space for a maximal possible char string (32k). When you call this procedure from pl/sql, pl/sql engine knows maximal length of the string that you expect, because you have defined length for the variable that will hold out parameter (v1 and v2). As for original problem, you can set maximal expected length of the parameter, if you will use OracleCallableStatement instead of CallableStatement and use this function: void registerOutParameter(int paramIndex, int sqlType, int scale, int maxLength) Special Oracle version of registerOutParameter for registering CHAR, VARCHAR, LONG, RAW and LONG RAW columns. http://download-east.oracle.com/otn_hosted_doc/jdeveloper/904preview/jdbc-javadoc/oracle/jdbc/OracleCallableStatement.html For example: OracleCallableStatement stmt = (OracleCallableStatement)conn.prepareCall ("begin ? := mychar(?,?,?); end;"); stmt.registerOutParameter(1,Types.CHAR); stmt.setString(2,"this is a test"); stmt.registerOutParameter(3,Types.CHAR, 0, 50); stmt.registerOutParameter(4,Types.CHAR, 0, 50); Output: JDBC driver version is 10.1.0.3.0 Return length is: 50 Trimmed string is: this is a test Trimmed string length is: 14 On 8/4/05, Jared Still wrote: > Yes, but even so, PL/SQL does not pad the CHAR input parameter out to 32k. > It will be the length of the string without padding. > -- Edgar callto://edgar.chupit -- http://www.freelists.org/webpage/oracle-l