>>Seconding Craigs worries about what functionality to put into which layer - esp. after the thread of firing a table lookup out of a control refresh.
>>Those tiny shortcuts add up over time - if you really think about selling your SW you should clean such things up instead of adding more small warts -
>>even if often the "correct" architecture will add more code / slowness to the app then doing it dirty.
>>Build stable and refactor / optimize a layer begins to eat into the performance ;-))
>>
>
>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.

The "warts" comment was aimed at the direct screen/datalookup connection not having ***any*** layer between them.
The "sale" comes from his recent musings of how to retire and how to proceed - and in such a case potential buyer will zoom on such issues ;-)