Re: When and when not to create SP/triggers

> I think stored procedures are ok but triggers NO! How do you debug > code where an insert,update or delete does not just run but can also > run other code which is not obvious from looking at the source code > to the original program? > I would disagree with that. Triggers can be VERY beneficial, so long as they're properly used. They can be used to enforce data integrity, as well as to enforce business rules, REGARDLESS of how an insert/update/delete was done. There's no way to circumvent a trigger aside from disabling it; if you code these things into your application, then anyone accessing the database via other means can change the data without your rules applying. In general, what I would recommend against is the use of stored procedures which call SYSTEM, not the use of triggers. I would also recommend against using triggers that call "nested" stored procedures. For any given trigger, there should be at most one SP called. - Tom Girsch Database Systems Manager Arch Communications Group, Inc.