SQL Triggers and Other Trigger Enhancements in V5

[MCWebsite.Staff]

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
** This thread discusses the Content article: SQL Triggers and Other Trigger Enhancements in V5 **
0

[ACT]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
Hi Skip, Nice article... Can I used a trigger for a remote file( a DDM defined ) or through a connection to a remote Database. Thanks in advance. Tony

[UserInHisName]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
Hi Skip, Thanks for the article. My knowledge in triggers is limited, but, I am confused with the read trigger event, as far as the practical use of it. It is a very dangerous tool, from the performance point of view. Any ideas? Thanks in advance! Albert

[laytondavis]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
I too am new to triggers, but the only use I can see would be the odd situation where you have to know who accessed a file and/or where they accessed it from. In situations where you are dealing with ultra sensitive information it would seem that the audit trail could be worth more than the performance.

[Guest.Visitor]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
READ triggers were added for some specific industry like HIPPA, but I forget exactly. They used to be a performance hog. Probably still are. Be careful with triggers. Anyone or any program that does a CRTDUPOBJ on a file is also getting the trigger definitions. So if you start updating your "test" file, you are accidentally firing triggers. Use CPYF of 1 record followed by CLRPFM instead, to get an empty copy of a file. Chris

[S.Marchesani]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
Carlos, If you go back and review the article you will see that you're question is answered there. The first paragraph under Read Triggers says the following: Read triggers have been implemented in OS/400 to satisfy a U.S. federal statute (HIPAA) requiring that all access to patient records in the medical profession be logged and auditable. From your perspective (programmer perspective) read triggers have no practical use and you should not use them Skip

[S.Marchesani]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
Tony, Thanks for the kind words re the article. A Trigger can only be added to an actual physical file (should be exteranlly described) on the system where the physical file resides. Therefore you cannot add a trigger to a remote file. Skip

[OzzieH]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
I've come to dislike triggers unless they are used sparingly. If a trigger is placed on a heavily used file, and if, for whatever reason, one needs to remove/add the trigger, you're hosed---due to the file being locked. These headaches can be lessened through a disciplined change management system, but for shops lacking in this area, I've found it be a problem. The trigger program is locked too. Some use the technique where the actual processing is performed one layer beneath, i.e., the trigger program calls another program which actual performs the processing. I thought this to be a swell solution until I ran into a case where a signature mismatch was detected in the second-level trigger program (due to a less than 100% successful conversion). When that occurs, the program isn't even called---therefore you can't monitor for the error in the program in which the signature mismatch was detected. You CAN monitor for it in the first-level program, but then what do you do with the error once its detected?---looking at it as a black box, the i/o operation failed in some manner. To know, more code has to be written. Then there's the hit on performance [snip the comments]. That's lead me to the conclude that unless your triggers and trigger methodology are ROCK-SOLID and robust, then sooner or later, you are apt to get bit by them. I'm sure the keyword here is "depends", as in, it depends on the shop, the application design, frequency of database changes, etc. Regardless, I have yet to fully buy into Triggers. Conceptually they are great. In real life though? I am not so sure.

[David Abramowitz]

SQL Triggers and Other Trigger Enhancements in V5

** This thread discusses the article: SQL Triggers and Other Trigger Enhancements in V5 **
Os wrote: Some use the technique where the actual processing is performed one layer beneath, i.e., the trigger program calls another program which actual performs the processing. This technique has worked just fine for me in the past. The first time working with triggers was quite an ordeal. Once I figured out that the trigger program should just be a shell that submits or calls other programs, it all worked O.K. Dave