SQL Server Service Broker calls the stored procedure to perform a cross-library operation, regardless of how it is set to always prompt that the server principal "SA" Cannot access the database "dbname" under the current security context.

With SQL Server's own Message Queuing service Borker, the call to the stored procedure, a cross-library operation was performed, first with a user, the permissions are sufficient, but always prompted the server principal "user" Cannot access the database "dbname" under the current security context.

Thinking is a structural problem, change sa or not. Find a Microsoft article that prompts for an ALTER database current_db SET trustworthy on

I set the cross of the library or not. Finally write your own test code, the code is as follows:

Create Databasetest1Create Databasetest2 Usetest2Create TableT_1 (IDint, ddate date)Insert  intoT_1 (Id,ddate)Values(1,GETDATE()) Usetest1Create procp_test with EXECUTE  asOWNER asbegin Select GETDATE() Select *  fromtest2. T_1Endexecp_testALTER DATABASETest1SETTrustworthy onALTER DATABASETest2SETTrustworthy on

Two libraries are SET trustworthy on but can be ... A day of tossing .....

EXECUTE as OWNER sets the execution context for the session. The queue will not go out, to solve there are two methods, the above is one of the methods, the other is the certificate ....

SQL Server Service Broker calls the stored procedure to perform a cross-library operation, regardless of how it is set to always prompt that the server principal "SA" Cannot access the database "dbname" under the current security context.