From dgoulet@vicr.com Mon, 06 Aug 2001 10:16:56 -0700 From: dgoulet@vicr.com Date: Mon, 06 Aug 2001 10:16:56 -0700 Subject: Re:3rd Party Java and Oracle Triggers Message-ID: MIME-Version: 1.0 Content-Type: text/plain ED, I'll agree with you, not knowing exactly what that app is doing could create all kinds of havoc. Also, if the database as laid down by the vendor does not have RI inside the DB doing so may cause the application to cease functioning. That is because (like PeopleSoft for instance) they enforce the RI inside the application and may populate the child records before the parents. This will cause your RI triggers to fail. What may be a better idea is to replicate the desired tables from the third party db into your Oracle financials DB and then do whatever populating of the Oracle financials is required. Dick Goulet ____________________Reply Separator____________________ Author: Ed Maurer Date: 8/6/2001 10:05 AM In the course of customizing one of our 3rd party apps that uses Entity Beans to do multiple inserts to some tables, It has been decided we'd use triggers on the tables to do some RI logic and insert essentially duplicate data into another database - Oracle Financials interface, to be exact, I've been opposed to this methodology, on the grounds that nobody here can tell me exactly how this app is behaving in the first place. I've heard that some beans do stupid (sic) things like insert a row, then update each column in the course of a single transactional insert, thus requiring both insert and update triggers; performance could be nightmarish, assuming we don't hit 4091 errors even trying to write the code. Unfortunately, without some hard facts, I'm going to have a hard time convincing anyone this is bad practice. And without tools to see exactly how the object(s) behaving, I won't be able to prove it on our development platforms either. Anyone have any experience here, or ideas for tools (besides packet capture) that can assist ? TIA Ed Maurer

In the course of customizing one of our 3rd party apps that uses

Entity Beans to do multiple inserts to some tables, It has been

decided we'd use triggers on the tables to do some RI logic and

insert essentially duplicate data into another database - Oracle

Financials interface, to be exact,

I've been opposed to this methodology, on the grounds that

nobody here can tell me exactly how this app is behaving

in the first place. I've heard that some beans do stupid (sic) things like

insert a row, then update each column in the course of a single

transactional insert, thus requiring both insert and update triggers;

performance could be nightmarish, assuming we don't hit 4091

errors even trying to write the code.

Unfortunately, without some hard facts, I'm going to have a

hard time convincing anyone this is bad practice. And

without tools to see exactly how the object(s) behaving, I won't

be able to prove it on our development platforms either.

Anyone have any experience here, or ideas for tools

(besides packet capture) that can assist ?

TIA

Ed Maurer

-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: dgoulet@vicr.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).