Re: Performance of Triggered Stored Procedures

I have left almost all of the original article below. Is 'UPDATE STATISTICS' is run regularly (every night?) This will only make a difference if the tables involved are being altered a lot - if they are static and the above has been run since they reached their current size I don't think it will help. The other thought is that I've found indexes to be ignored in the following example: table( co_code char( 3 ), co_account char( 10 ), ...); index table on( co_code, co_account) select * from table where co_code = "XX" order by co_account fails to use the index (at least in 5.00 versions) whereas ORDER BY co_code, co_account uses it! In article <3vnj43$7ve@hermes.is.co.za> ddsihck@sunny.oed.db.za "Harvey Keown" writes: > We are having erratic performance problems with triggers. There are times > when an UPDATE to a table is quick, and the next day the same update > might take in excess of 30 seconds. It appears that the triggered SP is > doing a sequential scan of the host table and ignoring indexes. > While trying to find the problem a 'return' was placed as the first > statement of the triggered procedure. Performance is still unbelievably > slow. > The triggered procedure is fairly large +- 150 lines - could this have > any effect? > We use Online v5.1. -- ============================================================================ Sally Woolrich | This mail contains my personal sally@excelsis.demon.co.uk | views not those of my employer! ============================================================================