How do I ignore errors generated from a duplicate index insert within a trigger

Hi,

I have a legacy Adaptive Server Anywhere 6 database which i need to add a trigger to.

Within this trigger I need to add some data to a table but I dont care if the row already exists.  I dont really want to do a "select 1 from..." to test it's presence as I feel this imposes an overhead on the database.

Is there any way I can simply trap the duplicate primary key index error and ignore it?

Thanks.

James.
JAMESAsked:
Who is Participating?
 
grant300Commented:
Well, as a rule, you are better off with clean SQL than you are counting on handling an error condition.  Error handling is generally not highly optimized code in any application and DBMSs are no exception.  If you do a test, you will find that handling the error is many times slower than doing the IF EXISTS (SELECT * FROM MYTABLE WHERE....) RETURN

In addition, if you are going to insert a row, you are going to need the index page(s) in memory anyway.  The test SELECT makes sure they are there so the actual insert does not pay for the I/O twice.  Of course, if the index pages are already in memory, the overhead of the IF EXISTS (SELECT.... is pretty low to begin with.  I am also not sure what sequence the INSERT operation uses.  If it inserts (and logs) the row before it goes and tries to update the index before failing, you are eating a whole bunch of extra overhead.

Let's see, what else....  You have a problem if the trigger is fired on a multi-row verb.  ASA supports row-level triggers however, it is generally faster to write triggers as you would for ASE which only fires a trigger once per verb.  Set operations are usually the best way to go.

Finally, if your trigger causes an SQL error, you may find that ASA (this is an old version so excuse the imprecise answer) will stop execution of the trigger at that point and push the error up the stack.  This could make it tough or impossible to complete the base transaction.

So go ahead and do the IF EXISTS (SELECT.... operation in the trigger.

Two other thoughts:  If you are going to update the row if it exists, the cleanest way to write the logic is to always attempt the UPDATE and then look at the effected row count and/or status to see if it succeeded.  If it did, you can exit; if not, go ahead and do the INSERT.  This works because an UPDATE that finds no row to UPDATE is not an error and all it will have done is search the index for the row.

The other tidbit of information is that you should always to an EXISTS rather than a NOT EXISTS for performance reasons.  In this case, IF EXISTS (SELECT.....) RETURN is the quickest way out.

Regards,
Bill
0
 
JAMESAuthor Commented:
Wow - thank you very much for taking that time to write your comments.

"IF EXISTS" is what I will be using :-)

Many thanks again.

James.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.