Hi,
My views on this are :
Triggers in "invalid" state, re-compile automatically at run-time
on invocation. If they fail to compile, they abort with an error
"trigger failed re-validation".
This being the case, I do not understand as to why you need to
check for every minute as to whether the triggers are valid or not?
Also without any DDL changes, there is no way the triggers become
"invalid"! In your environment, do you have DDL changes on the=20
database time and again ?
Do you agree with me ? Is it that I am missing something here !
Regards
Rajagopal Venkataramany
=20
On Mon, 27 Nov 2000 02:50:40 -0800, ORACLE-L_at_fatcity.com wrote:
> =20
> =20
> Hi All,
> =20
> Oracle 8.0.5
> AIX 4.3
> =20
> Is there a method to make sure that no more updates can occur when a
> trigger becomes invalid.
> =20
> Situation:
> =20
> We have a number of triggers in our database that maintain intergrity of
> the data. A procedure checks every minute if the triggers are still vali=
d
> and if not blocks new connections. It does not boot out the existing
> connections. It also leaves a minute (or whatever interval we specify)
open
> for corruption.
> =20
> =20
> I was thinking of maybe have a trigger on one of the sys tables, but I
have
> no clue as to which one.
> =20
> =20
> =20
> TIA
> =20
> =20
> Met vriendelijke groet,
> =20
> Jacob van Zanen
> (Oracle DBA) Informatie Systemen
> =20
> Ernst & Young
> Informatie & Communicatie Technologie
> =20
> Kantoor Gouda
> Tel.: 0182 575316 (intern: 923 316)
> Fax: 0182 536311
> E-mail: nlzanen_at_ey.nl
> =20
> =20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> De informatie verzonden in dit e-mailbericht is vertrouwelijk en is
> uitsluitend bestemd voor de geadresseerde. Openbaarmaking,
> vermenigvuldiging, verspreiding en/of verstrekking van deze informatie
aan
> derden is, behoudens voorafgaande schriftelijke toestemming van Ernst &
> Young, niet toegestaan. Ernst & Young staat niet in voor de juiste en
> volledige overbrenging van de inhoud van een verzonden e-mailbericht,
noch
> voor tijdige ontvangst daarvan. Ernst & Young kan niet garanderen dat ee=
n
> verzonden e-mailbericht vrij is van virussen, noch dat e-mailberichten
> worden overgebracht zonder inbreuk of tussenkomst van onbevoegde derden.
> =20
> Indien bovenstaand e-mailbericht niet aan u is gericht, verzoeken wij u
> vriendelijk doch dringend het e-mailbericht te retourneren aan de
verzender
> en het origineel en eventuele kopie=EBn te verwijderen en te vernietigen=
.
> =20
> Ernst & Young hanteert bij de uitoefening van haar werkzaamheden algemen=
e
> voorwaarden, waarin een beperking van aansprakelijkheid is opgenomen. De
> algemene voorwaarden worden u op verzoek kosteloos toegezonden.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The information contained in this communication is confidential and is
> intended solely for the use of the individual or entity to whom it is
> addressed. You should not copy, disclose or distribute this communicatio=
n
> without the authority of Ernst & Young. Ernst & Young is neither liable
for
> the proper and complete transmission of the information contained in thi=
s
> communication nor for any delay in its receipt. Ernst & Young does not
> guarantee that the integrity of this communication has been maintained
nor
> that the communication is free of viruses, interceptions or interference=
.
> =20
> If you are not the intended recipient of this communication please retur=
n
> the communication to the sender and delete and destroy all copies.
> =20
> In carrying out its engagements, Ernst & Young applies general terms and
> conditions, which contain a clause that limits its liability. A copy of
> these terms and conditions is available on request free of charge.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =20
> =20
> =20
> =20
> =20
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: nlzanen1_at_ey.nl
> =20
> 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_at_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).
Regards
Rajagopal Venkataramany
Received on Mon Nov 27 2000 - 21:18:53 CST
