> I'm currently using SPs to allow insertions on a particular table (the
> main SP calls a number of other SPs to perform insertions into
> additional related tables when necessary), and I'm wondering if a lot
> of the functionality (ie data validation/integrity checking etc) that
> I'm writing into the SPs might be better located in triggers for the
> tables in question. The current approach works fine (so far), so is
> there a good reason for me to move any of the existing functionality
> into triggers? The db will only ever be accessed via php and Delphi,
> and I can control the ways in which it is accessed (ie insertions only
> performed via SPs if I so choose). I understand that using triggers
> offers me transaction safety, ie if one of the triggers in the process
> fails, the whole transaction will be rolled back - am I unable to do
> this with SPs? I guess what I'm wondering is: what will triggers give
> me that stored procedures won't?
> Thanks.