Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 66195 invoked from network); 20 Jun 2006 19:47:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Jun 2006 19:47:38 -0000 Received: (qmail 76427 invoked by uid 500); 20 Jun 2006 19:47:34 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 76270 invoked by uid 500); 20 Jun 2006 19:47:34 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 76232 invoked by uid 99); 20 Jun 2006 19:47:33 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jun 2006 12:47:33 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [195.130.137.74] (HELO asia.telenet-ops.be) (195.130.137.74) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jun 2006 12:47:33 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by asia.telenet-ops.be (Postfix) with SMTP id 508E616821E for ; Tue, 20 Jun 2006 21:47:12 +0200 (CEST) Received: from [213.118.77.113] (dD5764D71.access.telenet.be [213.118.77.113]) by asia.telenet-ops.be (Postfix) with ESMTP id 37D8A168298 for ; Tue, 20 Jun 2006 21:47:12 +0200 (CEST) Message-ID: <44984FAC.70405@pandora.be> Date: Tue, 20 Jun 2006 21:42:36 +0200 From: Sven Boden Reply-To: list123@pandora.be User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: user-java@ibatis.apache.org Subject: Re: executeBatch not returning int of records updated. References: <4961604.post@talk.nabble.com> <44984C9B.7010302@pandora.be> <4961768.post@talk.nabble.com> In-Reply-To: <4961768.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N From the Oracle 9i documentation: "For a prepared statement batch, it is not possible to know the number of rows affected in the database by each individual statement in the batch. Therefore, all array elements have a value of -2. According to the JDBC 2.0 specification, a value of -2 indicates that the operation was successful but the number of rows affected is unknown." ibATIS translates the -2 to 0. So it seems it doesn't work on batched statemements. Regards, Sven jaybytez wrote: >Is there a version of Oracle that this depends on. Currently in our J2EE >framework we can check the int[] and int size and value everytime we do a >delete/insert/update. We are actually able to do successful tests against >the value in an int against PreparedStatement.SUCCESS_NO_INFO for instance. > >For example, this currently works if I use straight Jdbc. > > int results[] = ps.executeBatch(); > for (int i=0; i int result = results[i]; > if ((result != PreparedStatement.SUCCESS_NO_INFO) && (result != 1)) { > BaseTO object = null; > if (list != null) { object = (BaseTO)list.get(i); } > throw new RuntimeException(label + " result=" + result + ", >expecting 1: " + > (object == null ? "" : object.toString())); > } > } > >Thanks for your info... > >-jay >-- >View this message in context: http://www.nabble.com/executeBatch-not-returning-int-of-records-updated.-t1819686.html#a4961768 >Sent from the iBATIS - User - Java forum at Nabble.com. > > > > >