Trigger

[David Rohlicek]

Diky moc, vlastne se to chova OK. Jen mi nedosli souvislosti.  Uz jsem 
chytrejsi ;-)

David


Honza Pazdziora wrote:

>On Tue, Jun 29, 2004 at 01:06:31PM +0000, David Rohlicek wrote:
>  
>
>>Hmm, to by asi resilo. Zkusim. Ja zil v predstave, ze kdyz pouziju:
>>BEGIN => INSERT => END Tak mi trigger tikne az po ENDu, ale on tika uz
>>po INSERTu. V te me aplikaci, ktera reaguje na trigger musim pouzit 2x 
>>SELECT a
>>pri tom druhem SELECTu mi to vrati jiz radek OK.
>>Nevim jestli je toto spravne chovani DB nebo ne. ????
>>    
>>
>
>Trigger samozrejme musi byt spusten v tom okamziku, kdyz se zpracovava
>dany prikaz (a to budto na urovni prikazu nebo jednotlivych zaznamu).
>Pokud totiz udelate trogger, ktery bude delat
>
>	new.jmeno := lower(new.jmeno);
>
>tak potrebujete, aby tato operace byla triggerem provedena, proste
>proto, ze v nasledujicich selectech v te same transakci chcete videt
>vysledek toho selectu.
>
>Ten problem je v tom, ze UDP nebo zapis do FIFO jsou veci mimo
>transakcni system. Takze se stanou, druhy proces na zaklade nich zacne
>cist, ale teprve at prvni transakce provede commit, tak budou zmeny
>viditelne.
>
>Neni to tedy tak, ze musite pouzit select dvakrat -- je to tak, ze jich
>klidne muzete pouzit dvacet a nic se nemusi stat, nebo ze prvni aplikace
>stihne provest commit jeste pred prvnim selectem.
>
>Reseni je pouzivat primo nastroje databazoveho serveru, ktere dovoluji
>asynchronni zasilani zprav prave az pri commitu. Mene hezke ale stale
>funkcni reseni je opakovane cist tabulku, do ktere Vam prvni aplikace
>zapise id zmeneneho zaznamu, a po zpracovani odtamtud to id smazat
>nebo si jinak poznamenat, ze uz jste zmeny zpracoval.
>
>  
>