I'm not a Service Broker expert, but essentially what you are doing is creating a queue by putting that data in another database. Service Broker may help with the security issue because I'd use the trigger to insert into a local Service Broker Queue which then would start a conversation with a queue in the target database which picks it up and processes it. So you'd define a message with the data you need.

SB might be overkill for your situation, but the pluses would be:

<ul>

<li>No need for cross database ownership chaining or security issues with inserting data across databases</li>

<li>It would also allow you to move the target database to another server in the future and you'd only have to change the Route to point to the new server with the service broker queue destination. My terminology may not be correct, but that's the general idea.</li>

<li>You get asynchronous processing. Once the trigger dumps the message in the local queue control is returned to the application. If the insert into the destination table fails for some reason the initial transaction doesn't fail. You still have the message and can fix the problem with the data or the insert process and re-process the transaction.</li>

</ul>