impact of trigger on sqlexec size

Hello. I am a fairly new Informix user and I have a question about triggers and their impact upon the size of an sqlexec process. I'm concerned about the sizes of sqlexec processes growing very large and consuming all the server's virtual memory. Environment: Informix SE 7.24 on IRIX 6.4 I have a table with 98 columns and an update trigger that logs any changes to the table. There doesn't seem to be anything special about the data types for the columns. I would characterize them as a fairly standard mix of integers, dates, money and char types. The only possible exception would be 3 columns of char(255). The trigger's psuedo-code looks like this: create trigger update_test update on test referencing old as pre new as post for each row # for each and every one of the 98 columns: when pre.col-name is not equal to post.col-name ( execute procedure log(col-name, pre.col-name, post.col-name, user) ) The stored procedure "log" simply inserts the passed-in values into an audit trail table. Each of updates to this table is for one row at a time. The size of the sqlexec grows as the number of columns in the update grows; I've seen the sqlexec range from 5M to as big as 100M. The behavior is easily created using dbaccess to post single update commands, so I'm fairly certain that the application code is not doing anything strange (although it certainly is possible). This leads me to my questions. Am I doing something strange in the trigger and/or the stored procedure? Besides modifying the application in order to limit the number of columns changed by a single update statement, is there anything I can do to limit the sizes of the sqlexecs so that all the virtual memory is not consumed? Are there other alternatives for maintaining an audit trail? (The audit trail has a requirement placed on it that reports are generated from it on an ad-hoc basis.) Thanks in advance for any help with this. Larry Larry Magiera magiera@syrres.com Syracuse Research Corporation