Priority: subtle problem explained

My last blog entry was a bit muddled; I think that I'll rewrite it before posting it on my LinkedIn page. Thinking about some of the collateral problems whilst walking the dog, I found an explanation for behaviour which I have taken as a given until now.

The primary key of the junction table linking devices and waivers was the autoincrement key of the device along with a synthetic autoincrement field (kline). It is tempting to calculate the value of kline in the screen's pre-insert trigger: this way, the field will have a value before the tuple is written to the database. Unfortunately, an attempt to do this will result in an error message, that kline does not have a value ... even though it does. But does it?

One has to remember that the internal, automatic, triggers always execute before any triggers which have been added to the screen. In this case, there is an automatic pre-insert trigger which checks that all the fields which constitute the primary key of each tuple have a value. Kline has yet to have a value when this automatic trigger is executed, which is why an error message is displayed.

This means that the value of kline should be calculated either in a pre-form trigger or else in the post-field trigger of a mandatory field (in this case, the waiver code). This is what I have done, precisely because inserting the calculation in the pre-insert trigger doesn't work. Only now have I understood exactly why this is so.