>This may or may not help you but SQL Server 7 has several store procedures that enable OLE Automation with SPs and Triggers.
>
>sp_OACreate - Create an instance of an OLE COM object
>sp_OAGetProperty - retrieve a property setting
>sp_OASetProperty - set a property setting
>sp_OAMethod - execute a method of the object
>sp_OADestroy - get rid of the OLE COM object
>sp_GetErrorInfo - the name says it all
>
>You could create an instance of your COM object in a trigger and communicate all you want. Unfortunately there is no spOAGetObject so you have to create a new instance every time.
>
>Is this what you were looking for?

I dunno, but it sounds useful. I'll look into it.
>
>Although, I have a question about this. I can see where the initial data management would be handled by the middle-tier object. It could check for the existence of an object (or one of its properties) and then update the back-end data. But why would the trigger have to access this information? IMO, the trigger should handle data releated items. Once the business object has determined an update should take place, the trigger should simply run.

What they are trying to do is prevent technically-savvy users from changing the data except thru the system. It's a security issue rather than a business logic issue.