We have some stream-of-consciousness notes from the 4Dv6 Triggers class:

• Triggers operate on add, modify, delete, and load record.
• Triggers operate at the lowest level of the database, and are called just before the internal database engine check for unique value in a field. This is because the trigger may change the value of the record itself.
• File procedures will still exist in 4Dv6, but only when a 4D Customizer Plus style 4Dv3 compatibility setting is active. If it is turned off, file procedures are converted to table methods, which are also called triggers.
• You have ot be careful what you do in a trigger; for example, you wouldn't want to attempt to communicate with another process inside a trigger. Also, the external callbacks to add records are not allowed in a trigger. In the same way, 4D open is not allowed in a trigger.Other than that, triggers are written in plain old 4th Dimension.
• Q: Is a trigger a table method? A: Yes. The problem is: it's purely a marketing thing. The press likes the word triggers. They are exactly the same thing.
• Q: Is there a way to assign a plain English error mesage? A: Via ON ERROR CALL
• (The Explorer has a long list of constants from which you can drag and drop into the procedure editor.)
• The constant Database event is used to decode which flavor of trigger is operating in the table method.
• An exended version of Modified is used to detect which fields have been changed, and manipulated with the Old function.
• Levels are supported for the triggers when relations are involved; There is NO LIMIT to the cascading depth to which this can be invoked. These are implemented via two commands Trigger level and TRIGGER PROPERTIES, which is passed the level number. It returns three parameters: Database event of the trigger, the table number, and the record number.
• What about when someone else has locked a record you encounter when you are cascade deleting? This is where the new In transaction command comes in.
• Q: Can you start a transaction in a trigger? A: Yes, but I would not do that. Remember, the purpose of a trigger is to enfore rules. It should be a piece of code that executes quickly. The management of your transaction should be kept at its invoking .
• Q: Say a user is editing a line item, and you call delete customer. What if it encounters an error at the very end? A: Transactions.
• Q: Do you see a time in the future when we might have nested transactions? A: Next year we will speak about version 7. It's something we are thinking about.
• Q: Say you have an ARRAY TO SELECTION. Will it invoke the trigger every time? What if it encounters an error? A: It is like today; triggers do not help with that.
• Q: Can you programmatically turn off the triggers? A: No. We thought about taht for a long time, and decided to not implement it. There's nothing preventing you from setting up an If statement inside the trigger to turn it off.
• Q: If you encounter an error in a deeply-nested trigger, does it abort all the triggers? A: No. It is up to you to check the error result (in the OK variable) after each operation.
• Q: How do triggers interact with the automatic deletion controls? A: Automatic deletions come first, triggers next,then index checking. (To be confirmed.)
• When searching for an already-existing unique key when adding a record, you no longer have to PUSH the record, SEARCH, and POP. This can be handled in triggers by using a QUERY with a limit of one, and sending the result to a variable. (BG comment: WOW!) The syntax looks like this: QUERY([File];[File]Field=[File]Field) -- it looks strange, but it works, since the current value of the record is being comapred against the records out in the field.
• Note that the query limit is persistent, so you must be careful to change it back.
• Q: How do you reset your query limit? A: Set Query Limit 0, which means return all.
• Q: Is that file specific? A: No. For all queries.

Back to the DEVCON Update Page...