Two weeks ago, I wrote these prophetic lines:
- All triggers execute in alphabetical order.
- 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.