With two databases A and B on the same SQL Server 2014 instance, I've written a series of scripts trying to do the following (written in very high level pseudo code):
-
User Updates table
A.dbo.Main
-
A.dbo.Main
has a trigger onUPDATE, DELETE, INSERT
that calls a stored procedureA.CallProcInB
-
A.CallProcInB
then calls a stored Procedure in B calledB.RunComponentsUpdate
-
B.RunComponentsUpdate
then merges a view and a table calledB.dbo.A_View
andB.dbo.B_Table
.
The problem is I have gotten these series of scripts to work perfectly on a personal computer running SQL Server 2014 Express, with the exact same schema setup for the databases A and B, but when I set everything up on my company's main server running SQL Server 2014 I get the following error message:
System.Data.Odbc.OdbcException (0x80131937):
ERROR [42000] [Microsoft][ODBC SQL Server Driver][SQL Server]
The SELECT permission was denied on the object 'B_Table', database 'B', schema 'dbo'.
ERROR [42000] [Microsoft][ODBC SQL Server Driver][SQL Server]
The UPDATE permission was denied on the object 'B_Table', database 'B', schema 'dbo'.
I've tried giving the user activating the initial trigger all privileges on both A and B, as this was enough to fix the issue on my personal computer server. However, giving basically "god" privileges hasn't been enough to resolve this error on the server.
Best Answer
The permissions error is to be expected when you don't have things like Cross-Database Ownership Chaining and TRUSTWORTHY enabled, and aren't logging in as
sa
;-).This very similar to the problem described (and resolved) in my answer to another question here on DBA.SE:
Permissions in triggers when using cross database certificates
However, in that case there was a Trigger in Database B and that is not the situation here. Still, this should be fairly easy to solve and will use a setup similar to what is described in that other answer.
Here are the steps you need to do for your particular issue (all of which are shown in that other answer):
A.dbo.CallProcInB
Stored Procedure using that Certificate.EXECUTE
on theB.dbo.RunComponentsUpdate
Stored Procedure to the new Certificate-based User.That should be all you need.
Please be aware that any changes to the
A.dbo.CallProcInB
Stored Procedure will cause it to lose the signature. In those cases, just executeADD SIGNATURE
again.