Oracle impact vraag

[Verwijderd]

Ik zit met een groot probleem. Ik moet een applicatie maken waarbij enkele afdelingen van ons bedrijf SQL direct op een Oracle productie database moeten afvuren, zonder dit via de DBA's te regelen.

Op zich via ADO leek me dat niet zo'n probleem, maar het vereiste is dat de te ontwikkelen tool precies voorafgaand moet laten zien wat de situatie voor het SQL commando is geweest, en wat het daarna is geweest.

Ook dat was nog wel te overzien, maar het probleem is nu dat Oracle volgens mij ook triggers heeft, waardoor ik dus niet meer kan overzien wat de gevolgen zijn van zo'n dergelijke query.

En dan nu de echte vraag

Hoe kan ik via een (VB) applicatie aan een Oracle database zien wat voor een impact een uit te voeren SQL statement zou hebben, rekening houdend met eventuele triggers, bussines rules, etc wat op de Oracle database kan zijn vastgelegd.

Ook een belangrijke vraag

Wat voor een mogelijkheden heeft een Oracle database behalve triggers die ook effect kunnen hebben wanneer een SQL statement wordt afgevuurd en waar ik dus ook rekening mee dien te houden?

Ik hoop dat iemand me hiermee kan helpen, vind het persoonlijk een erg moeilijk probleem.

[JaQ]

als je enkel queries afvuurt (selects dus) zal je nooit triggers laten afgaan. Wat je uiteraard wel in de gaten moet houden, is dat je die database niet gaat overbelasten. Over het algemeen is er een hele goede reden waarom een DBA eerst de query wil zien die je gaat gebruiken.

[Verwijderd]

Helaas mogen ze meer dan alleen simpele select statements uitvoeren. Ook update, insert en delete is toegestaan. Ik ga al wel een heeeel groot "ik ben niet verantwoordelijk voor wat jullie willen" document opstellen, maar het zou toch gemaakt moeten worden.

Ik vraag me alleen af hoe je in VB bijvoorbeeld kan achterhalen welke triggers etc er nou precies in de database zitten, dat is me nog steeds niet gelukt :-;(

[FastWallie]

Oef, dat klinkt inderdaad heel erg gevaarlijk. IS het een optie om bij elke tabel een userid (als een soort owner op te nemen). Daarmee kun je een set van rules maken per userid. Als je het updaten / deleten op tabel niveau af wilt dwingen kun je dit mbt van grants regelen.
Er zijn wel mogelijkheden om alle triggers (en andere database objecten te bekijken en daarna af te vuren met bepaalde parameters)

[Verwijderd]

FastWallie schreef op 13 September 2002 @ 16:37:
Oef, dat klinkt inderdaad heel erg gevaarlijk. IS het een optie om bij elke tabel een userid (als een soort owner op te nemen). Daarmee kun je een set van rules maken per userid. Als je het updaten / deleten op tabel niveau af wilt dwingen kun je dit mbt van grants regelen.
Er zijn wel mogelijkheden om alle triggers (en andere database objecten te bekijken en daarna af te vuren met bepaalde parameters)

De Oracle database heeft al wel per user rechten ingesteld, daar zit waarschijnlijk niet het grootste probleem. Het probleem is alleen dat als iemand simpel denkt een record toe te voegen, er misschien wel een e-mail bericht naar een klant gestuurd kan worden door een trigger die afgaat. Zulk soort grappen wil ik dus laten zien aan de gebruiker, dan weet ie tenminste waar HIJ verantwoordelijk voor is.

Ik heb alleen nog steeds niet uitgevonden hoe ik triggers etc kan achterhalen

[Lister]

Ik ben geen Oracle expert, maar als het goed is staan alle database objecten in Oracle in dictonairy objecten met namen zoals dba_<objecten>, user_<objecten>.
Een select op dba_triggers zou alle database triggers moeten tonen en daar staat dan wel weer in bij welke tabel een trigger hoort.
Je moet echter wel voldoende rechten hebben om die gegevens op te vragen.

Zo zou je aan het trigger statement moeten komen, dan heb je volgens mij nog het probleem hoe je dat wil representeren aan de gebruiker en of die dat dan een beetje snapt.

[JaQ]

triggers en de omschrijving daarvan kan je uit all_triggers halen.
Als er in die triggers procedures, danwel functies (eventueel in packages) worden aangeroepen, kan je die uit all_source halen. (Uiteraard mits je de correct rechten hebt).

Als je even toad of pl/sql developer donwload (trial versions), kan je de triggers op je gemakkie bestuderen.

[Verwijderd]

Volgens mij is het dan nog steeds onmogelijk, ik ben er nu achter gekomen dat een trigger ook gewoon een DDL applicatie op kan starten, en dan weet ik helemaal niet meer wat de gevolgen allemaal zouden zijn.

Ik denk dat wat ze willen gewoon niet mogelijk is. Wanneer er functionaliteit in de DB is gebakken kan een tool dat nooit allemaal achterhalen.

[Tomatoman]

Welke triggers er allemaal in die database zitten en wat ze precies doen, zou de DBA je moeten kunnen vertellen. Als hij dat niet kan/ wil, moet je je afvragen of jij dan wel verantwoordelijk moet zijn voor wat je gebruikers in de database uitvoeren. De DBA zou duidelijk moeten aangeven waar de 'gevaarlijke' triggers in de database zitten en welke weinig spannend zijn. Zo niet, dan kun jij geen maatregelen in je progsel nemen om rampen te voorkomen.