Trigger Happy Rotating Header Image

Why Trigger Happy?

For my first blog post, I thought I would explain the name of my blog.  I have always enjoyed working with database triggers – they represent a fairly unique and challenging way of programming, but it really goes back to when/why I started working with SQL server.

Back in the day, I was working with MS Access (I started with 1.0, but I believe I was already on 2.0 at the time I discovered SQL server).  I did not come to SQL server because of scalability – my application was pretty small, and believe it or not, Access was actually handling it fairly well.  Somehow I caught wind of the concept of a database trigger, though, and it intrigued me.  I read up on it and discovered that with a “real” DBMS, you could make the tables themselves run programs when you did data modifications on them – and these programs could go off and do anything you wanted them to.  This was just such a cool and novel idea that I upgraded my application to SQL server straightaway and became very “trigger happy” in a bad way.  I used triggers for everything and went too far with them, but this is what tends to happen when you’re self-teaching a technology.

Since then I have, of course, discovered many other advantages of SQL server over Access and I have never looked back.  I spent years writing applications front-ended with Access, but I haven’t used Access’s JET database engine for probably about 10 years now.  Toward the end of my Access career, I was working primarily with Access ADPs.  Today I’m almost exclusively a database developer and administrator and pretty much never touch front ends at all.  The title of my blog reminds me of how I started on the path to where I am.

The title is also a stark reminder to be careful with jumping on the bandwagon of a new technology.  I still have an affinity for triggers and jump at the chance to write one when the situation warrants, but as we all should know, a trigger runs as part of the transaction that fired it, and (typically) after the data modification it is responding to so they are not the best place for things like validation logic.  They can easily be misused and cause concurrency issues.  From this standpoint, it is important that I am not too “trigger happy”.

Finally, I am into hunting, so there is even the whole double-meaning thing going on.  I hope you are picking up on the sense of irony here as opposed to becoming more and more alarmed:  regardless of how one can be “trigger happy”, it is rarely a good thing.  The hope is that, in contrast to common implications of its title, this blog will definitely be a good thing.

Leave a Reply

Your email address will not be published. Required fields are marked *

The CAPTCHA cannot be displayed. This may be a configuration or server problem. You may not be able to continue. Please visit our status page for more information or to contact us.