From oracle-l-bounce@freelists.org Fri Mar 26 08:39:38 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i2QEdcd28955 for ; Fri, 26 Mar 2004 08:39:38 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i2QEdbo28935 for ; Fri, 26 Mar 2004 08:39:37 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 22023390E06; Fri, 26 Mar 2004 09:36:44 -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 17285-87; Fri, 26 Mar 2004 09:36:43 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D9095390E03; Fri, 26 Mar 2004 09:36:23 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 26 Mar 2004 09:34:53 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 487753909C7 for ; Fri, 26 Mar 2004 09:34:52 -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 17609-10 for ; Fri, 26 Mar 2004 09:34:51 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 9F594390D44 for ; Fri, 26 Mar 2004 09:34:51 -0500 (EST) Received: from phys-giza-1 ([129.147.4.102]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i2QEfPMr022242 for ; Fri, 26 Mar 2004 07:41:31 -0700 (MST) Received: from sun.com (sr1-ubrm-10.Central.Sun.COM [129.147.4.219]) by giza-mail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HV600IUVU6INH@giza-mail1.Central.Sun.COM> for oracle-l@freelists.org; Fri, 26 Mar 2004 07:42:18 -0700 (MST) Date: Fri, 26 Mar 2004 07:42:18 -0700 From: Daniel Fink Subject: Re: Strange Problem To: oracle-l@freelists.org Message-id: <4064414A.696BB191@sun.com> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.9 sun4u) Content-Type: multipart/alternative; boundary=------------14028863C0EC0E9AC7603B0A X-Accept-Language: en References: <007201c41272$fa64d3a0$4a0710ac@lan.magma.co.in> <40634A5E.A82302A5@sun.com> <00f201c412fa$aa7c18c0$4a0710ac@lan.magma.co.in> X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 1889 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: Daniel.Fink@Sun.COM Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org --------------14028863C0EC0E9AC7603B0A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------14028863C0EC0E9AC7603B0A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Deep,

As it was a 3rd party product, they ended up sending a patch for the application that solved the problem. I think it was a combination of the fix to the memory corruption and additional exception handling.

The best way for you to address it is to always handle errors in pl/sql and never let 'when others' cause a commit.

Daniel
 

Arghadeep Chatterjee wrote:

 Hi Daniel,DO you remember how you solved it?Deep
----- Original Message -----
Sent: Friday, March 26, 2004 2:38 AM
Subject: Re: Strange Problem
 Deep,

I can't comment on specifics, but it reminds me of a similar situation. Periodically, a 3rd party app would 'lose inserts'. Turns out that the application was not handling errors, so would insert record 1 into table 1 then insert record 2 into table 2 (but this insert would result in an error that was not handled by the application) and a commit was issued. So the first insert was committed and the second was 'lost'.

Turns out a memory corruption was causing the application to send bad data, Oracle would reject it.

Good luck.

Daniel
 

Arghadeep Chatterjee wrote:

   Hi All,I am facing a strange problem the details of which is given belowHp-UX 11.11,Oracle 9.2.0.1.0Users arnd 213Mem 4GBProc 2Type of application Custom ERP using Oracle Forms and Reports 6iNow the problemfrom one of the forms an Oracle DB procedure is called say xthis procedure creates a curson say ynow it goes on updating three tables say row 1,2,3 .The strange thing iswhile working at some times this application inserts the three rows for thesay first table and compleletely misses to update the same value to anothertable say row 2 and 3 while it updates row 1.I am unable to find a logical reason forthis as commit is issued at the end of the procedure and at certain times it justworks as it is intended to work.Any pointers anyone.ThanksDeep
--------------14028863C0EC0E9AC7603B0A-- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------