🚀 go-pugleaf

W artykule <bd3d62f4-32c8-4500-af40-3c2aeee9fb99@googlegroups.com> goo-mlyny@ciach.net napisal(a):

> Mam taki prosty trigger:
> CREATE OR REPLACE TRIGGER AC_TG_POTW_EDI
> BEFORE INSERT
> ON ZAMOWIENIA_KLIENTOW 
> REFERENCING NEW AS New OLD AS Old
> FOR EACH ROW
> DECLARE
>   nowa_data date;
> BEGIN
>   if :new.KOD_RODZAJU_ZAMOWIENIA='EDI' then
>    :new.POTWIERDZENIE_ZAMOWIENIA:='T';
>     nowa_data := sysdate;
>    :new.DATA_WYDANIA := to_date(nowa_data);
>     --:new.DATA_WYDANIA := nowa_data; --tak też próbowałem, bo już kombinuję, jak koń...
>    :new.KOMENTARZ_NA_ZLECENIU:='Data wyd.: ' || TO_CHAR(nowa_data) || ' [-] ' || TO_CHAR(:new.DATA_WYDANIA);
>   end if;
> END AC_TG_POTW_EDI;
> /
>
> Pole DATA_WYDANIA jest typu date.
> I po wprowadzeniu danych - w polu POTWIERDZENIE_ZAMOWIENIA mam T,
> w polu KOMENTARZ_NA_ZLECENIU - mam 2x datę. 
> Niestety - w polu DATA_WYDANIA na końcu - czyli jak zrobię select * from ZAMOWIENIA_KLIENTOW - mam null.
> Tak się domyślam, że może być jeszcze jakiś inny trigger, który wykonuje się później, niż mój - i zeruje ustawioną wartość. Ale nie wiem, jak namierzyć miejsce, gdzie to się dzieje. Cała struktura bazy, tabele, triggery - nie są moje, jest ich naprawdę mnóstwo - i nie mogę póki co znaleźć miejsca, gdzie następuje zmiana.

W narzędziach typu PL/SQL Developer, Toad, itp., masz drzewko z hierarchią obiektów.
Klikasz na tabelce i rozwijasz listę wyzwalaczy na niej, a potem przeglądasz każdy
aż znajdziesz winowajcę. Ewentualnie możesz to sobie ręcznie sprawdzić:
select * from user_triggers t where t.table_name = 'ZAMOWIENIA_KLIENTOW';
select * from user_source s where s.name = 'TRG_BLA_BLA_BLA' order by s.name, s.line;

Jak łączysz się przez inny schemat niż ten sprawdzany to będziesz potrzebował
widoków systemowych dba_triggers/all_triggers, dba_source/all_source.

A tak na marginesie robienie TO_DATE na zmiennej typu DATE jest bez sensu.
Do TO_CHAR zawsze podawaj format, bo inaczej polegasz na bieżących w sesji.
Co jest raczej ryzykowne, zwłaszcza jak odpalasz coś z palucha, z crona, itp.
Np. TO_CHAR(nowa_data,'dd-mm-yyyy hh24:mi:ss')



-- 
Pozdrawiam,                           Piotr.Kuc-(szympans)-kuciak.net
Piotr M Kuć

> W narzędziach typu PL/SQL Developer, Toad, itp., masz drzewko z hierarchią obiektów.
> Klikasz na tabelce i rozwijasz listę wyzwalaczy na niej, a potem przeglądasz każdy
> aż znajdziesz winowajcę. Ewentualnie możesz to sobie ręcznie sprawdzić:
> select * from user_triggers t where t.table_name = 'ZAMOWIENIA_KLIENTOW';
> select * from user_source s where s.name = 'TRG_BLA_BLA_BLA' order by s.name, s.line;
Właśnie wydaje mi się, że przejrzałem wszystkie triggery robiące cokolwiek z tabelą ZAMOWIENIA_KLIENTOW i nie znalazłem niczego, co by wg mnie mogło zmieniać wartość pola DATA_WYDANIA... Myślałem, że jest może jakiś sposób, żeby założyć jakiś "watch" na polu - i czekać na moment, kiedy to pole ulega zmianie.
 
> A tak na marginesie robienie TO_DATE na zmiennej typu DATE jest bez sensu.
Po prawdzie to tak myślałem, to była raczej desperacka próba znalezienia jakiegoś punktu zaczepienia, żeby określić przyczynę, dlaczego to jedno pole nie chce się uaktualnić.

> Do TO_CHAR zawsze podawaj format, bo inaczej polegasz na bieżących w sesji.
> Co jest raczej ryzykowne, zwłaszcza jak odpalasz coś z palucha, z crona, itp.
> Np. TO_CHAR(nowa_data,'dd-mm-yyyy hh24:mi:ss')
Zawsze tak robię, w podanym przykładzie opuściłem, żeby nie zaciemniać treści.

No nic - kombinuje dalej.