Your comment was well taken. After I thought about what I was trying to do, I see that "moving" this procedure to the DB would require for me to set it up (and maintain) in all customer databases. Writing the procedure to the application (even though 3 applications) would allow me to NOT to deal with DB issues with all customers. And I will maintain just my code in 3 places. I think it is better approach.

>I agree that there are many approaches to solving a problem that will result in the correct answer. However, often times we take shortcuts that lead to maintenance issues or inability to extend the application. This is called technical debt. Sometimes it's acceptable to take on that debt. I can't comment if any of the solutions fall into the issues I just mentioned because I don't have enough understanding of the application. Only one person can figure that out. My original comment was made to cause additional thought into the implementation.
>
>
>>Well..."that depends". Some software is never meant for sale.
>>
>>Many internal application environments deal with the issue of data being changed from many applications, external jobs, or even manual updates by DBAs. Database triggers, for all their warts, are still very reliable for capturing changes. As far as what mechanism scans any control table, maybe you have another database job using Agent/some other scheduler, maybe you have an app. Again, "depends". :)
>>
>>The approach that Sergey described in a prior post is a perfectly acceptable (and reliable) method, especially for internal applications.