Abhängigkeiten in Triggern - welche Felder werden geschrieben?

[colaflasche]

Hallo,

ich kann ja über die rdb$descritions die Abhängigkeiten im Firebird ermitteln, also in meinem speziellen Fall, welche Felder in welchem Trigger verwendet werden, Z.B. so:

Code: Alles auswählen

  select rdb$dependencies.rdb$field_name
      , rdb$dependencies.rdb$depended_on_name
      , list(trim(rdb$dependencies.rdb$dependent_name), ', ') as Objekte
       , count(*) as anzahl
    from rdb$dependencies
    join rdb$triggers on rdb$triggers.rdb$trigger_name = rdb$dependencies.rdb$dependent_name
--   WHERE rdb$dependencies.rdb$field_name IN ('ANG_AM', 'ANG_BEN_ID', 'ANG_DT', 'ANG_VON', 'GEA_AM', 'GEA_BEN_ID', 'GEA_DT', 'GEA_VON')
     and rdb$dependencies.rdb$dependent_type = 2
     and rdb$triggers.rdb$system_flag = 0
     and not rdb$dependencies.rdb$field_name is null
group by rdb$dependencies.rdb$field_name
       , rdb$dependencies.rdb$depended_on_name
  having count(*) > 1
order by count(*) desc

Kann ich auch irgendwie ermitteln, welches Feld davon gelesen wird und welches geschrieben wird? Oder muss ich dafür den Triggerquelltext analysieren?

Gruß Jan

[martin.koeditz]

Hallo Jan,

ich bin mir nicht zu 100% sicher, aber vermutlich wirst du die Triggerdaten analysieren müssen. Ich werde hier aber nochmals recherchieren.

Gruß
Martin

[bfuerchau]

Wobei dies durchaus schwierig wird, da man Felder umbenennen kann und Views sowie Instead-Of-Trigger dies wiederum verbergen können. Immerhin ist ja nun auch noch dynamic SQL erlaubt. Unter bestimmten Restriktionen sind auch Views update fähig.

[vr2]

Hallo Jan,

heiliger Strohsack, wofür brauchst Du das denn? DB geerbt, die so viele oder so komplexe Trigger hat, dass unklar ist, wo die schreiben?

Syntaxanalyse der Trigger kannst Du eher vergessen. Wenn Du tatsächlich einen externen (P)SQL-Parser für Firebird hinkriegst, hätte vermutlich ein Teil der Firebird-Community Interesse daran

Eine Möglichkeit wäre, von der Tabellen-/Feldseite ranzugehen und dort IUD-Trigger zu definieren. Wenn die feuern, kannst Du Dir über monitoring tables den call stack holen und darüber den Trigger ermitteln. Evtl lasst sich das auch tracen, ist aber nur eine Vermutung ins Blaue.

Grüße, Volker

[bfuerchau]

Was bitte ist ein IUD-Trigger?
Ein Callstack kann dir i.d.R. nur tatsächliche Code-Aufrufe anzeigen. Da der PSQL.Trigger im Endeffekt ja von Firebird ausgeführt wird ist im Callstack dann die Firebirdinstanz ausgegeben.

[colaflasche]

Hallo Zusammen,

vielen Dank für eure Antworten!

@Volker: Komplex nicht, es ist einfach nur die Masse und zu gewissen fällen kann ich mir gut Trigger automatisiert anlegen. Nun will ich die Altlasten entfernen, bzw. in Zukunft verhindern, dass ein bestimmtes Feld doppelt geschrieben wird. Gelesen werden darf das Feld, so oft, wie man will.
Im speziellen geht es um Anlage- und Änderungsdatum eines Datensatzes.

Einen Richtigen Parser der alles komplett abbildet brauche ich ja noch nicht mal, ich muss nur wissen, wann die geschrieben werden, aber der hinweis mit den IUD-Triggern war schon mal gut. In meiner Abfrage werte ich nun den rdb$trigger_type aus. wenn es ein After-Trigger ist, dann kann er nicht in "new." schreiben.
Am Ende blieben zwei Trigger übrig, die ich von Hand gesichtet habe.

@bfuerchau:
> IUD-Trigger

Insert/Update/Delete-Trigger, also ein Multiaktionstrigger.

Viele Grüße, Jan