Bitten by the bug

Two weeks ago, I wrote these prophetic lines:

1. All triggers execute in alphabetical order. 
2. Always read the source code to see how the program achieves something before trying to extend that functionality

The first lesson will be taken to heart, but I suspect that I will forget the second until I come across it again.

It didn't take long for the first lesson to be forgotten. My task was as follows: in the Projects form, if a contact person is added then insert into a son form data based on that person. Simple, no? I wrote some code and it worked perfectly. 

This morning I received two phone calls complaining about this screen; both users had a similar error message but each was referring to a different field. While I was talking to the second user, the penny dropped: I was trying to insert data into the son form before the parent form (ie the project itself) had been created. In other words, my post-insert trigger was executing before the default post-insert trigger. 

So I changed the name of my trigger and now the code works properly.

Thinking about this some more, the explanation doesn't seem right. If I have written a post-insert trigger, then the project has already been inserted (that's why it's called post-insert), so the alphabetical order of triggers isn't relevant. I'm inserting data into a private table so this isn't dependent on anything else.

Referring to the above phrase "it worked perfectly", obviously my testing was at fault. I was testing the post-update trigger but not the post-insert trigger. The real lesson to be learned is to call all private post-insert triggers ZLOB_POST-INSERT (at least, something beginning with Z). This way, the alphabetical order 'bug' will not bite me again. It's not a bug in the program but rather in my understanding.