Dear Jonathan,
Thanks for your will to help.
It would be a bit difficult to clean up everything as much as possible
(while keeping the problem) and send the skeleton.
It looks like the A_AU trigger I mentioned solved the problem.
Actually, the situation I painted is much much simplified compared to the
real one (about 20 or more tables are accessed during that "simple 1-line
update"). What I'd probably use best, are some generic guidelines:
* what is sure about trigger execution order?
(Cristoph Haller partially answered my question, quoting future plans)
* are there generic recommendations what kind of things to put in
before and after triggers?
* how about FOR EACH STATEMENT triggers?
(we only use FOR EACH ROW triggers)
G.
------------------------------- cut here -------------------------------
----- Original Message -----
From: "Jonathan Gardner" <[EMAIL PROTECTED]>
Sent: Wednesday, August 13, 2003 4:54 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 13 August 2003 03:11, SZŰCS Gábor wrote:
>
> What may be wrong? Any ideas to re-organize parts of the triggers?
> May putting the update to an A_AU trigger help? I tried it, still
> have problems (not sure it's still the trigger order), but the
> trigger order is still strange for me:
I'd need some solid code to solve this. Can you send the create
statements and the insert statement that started it all? I get the
feeling that you may have more triggers than you really need.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
