Abhängigkeiten in Triggern - welche Felder werden geschrieben?

Forum zu diversen Themen rund um die Firebird-Programmierung

Moderator: martin.koeditz

Antworten
colaflasche
Beiträge: 5
Registriert: Fr 6. Mär 2020, 16:32

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
Benutzeravatar
martin.koeditz
Beiträge: 235
Registriert: Sa 31. Mär 2018, 14:35

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
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 198
Registriert: Mo 7. Mai 2018, 18:09

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
Beiträge: 79
Registriert: Fr 13. Apr 2018, 00:13

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
Beiträge: 198
Registriert: Mo 7. Mai 2018, 18:09

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
Beiträge: 5
Registriert: Fr 6. Mär 2020, 16:32

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
Antworten